Действительно, два типа не могут быть изменены после того, как они были инициализированы, но существуют некоторые различия между ними:
, Например, константа могла использоваться в этой ситуации:
public class MathValues
{
public const double PI = 3.14159;
}
И только для чтения было бы лучше для этого случая:
public class Person
{
public readonly DateTime birthDate;
public Person(DateTime birthDate)
{
this.birthDate = birthDate;
}
}
или
public class Person
{
public readonly DateTime birthDate = new DateTime(1986, 1, 24);
}
'константа' статична, таким образом, она совместно используется всеми экземплярами того класса и может быть получена доступ непосредственно (как MathValues. PI), тогда как 'только для чтения' не статично. Как следствие объявление как 'статическая константа' недопустимо, потому что константа является статическими, но 'помехами, только для чтения', законен
, 'константа' может содержать только целочисленный тип (sbyte, байт, короткий, ushort, интервал, uint, долго, ulong, символ, плавание, дважды, десятичное число, bool, или строка), перечисление или ссылка на пустой указатель (не классы или структуры, потому что они инициализируются во времени выполнения с 'новым' ключевым словом), тогда как 'только для чтения' может содержать составные типы, структуры или классы (при помощи нового ключевого слова при инициализации), но не может содержать перечисления
Есть несколько способов сделать это, в зависимости от того, что вы на самом деле хотите. Если у вас нет общих столбцов, вам нужно решить, хотите ли вы ввести общий столбец или получить продукт.
Допустим, у вас есть две таблицы:
parts: custs:
+----+----------+ +-----+------+
| id | desc | | id | name |
+----+----------+ +-----+------+
| 1 | Sprocket | | 100 | Bob |
| 2 | Flange | | 101 | Paul |
+----+----------+ +-----+------+
Забудьте о фактических столбцах, так как вы, скорее всего, в данном случае отношения покупатель / заказ / деталь; Я просто использовал эти столбцы, чтобы проиллюстрировать, как это сделать.
Декартово произведение будет соответствовать каждой строке в первой таблице с каждой строкой во второй:
> select * from parts, custs;
id desc id name
-- ---- --- ----
1 Sprocket 101 Bob
1 Sprocket 102 Paul
2 Flange 101 Bob
2 Flange 102 Paul
Это, вероятно, не то, что вам нужно, поскольку 1000 частей и 100 заказчики получат 100 000 строк с большим количеством дублированной информации.
В качестве альтернативы, вы можете использовать объединение, чтобы просто выводить данные, но не бок о бок (вы ' Мне нужно убедиться, что типы столбцов совместимы между двумя выбранными объектами, либо сделав столбцы таблицы совместимыми, либо принудительно их при выборе):
> select id as pid, desc, null as cid, null as name from parts
union
select null as pid, null as desc, id as cid, name from custs;
pid desc cid name
--- ---- --- ----
101 Bob
102 Paul
1 Sprocket
2 Flange
В некоторых базах данных вы можете использовать столбец rowid / rownum или псевдостолбец для сопоставления записи рядом, например:
id desc id name
-- ---- --- ----
1 Sprocket 101 Bob
2 Flange 101 Bob
Код будет примерно таким:
select a.id, a.desc, b.id, b.name
from parts a, custs b
where a.rownum = b.rownum;
Это все еще как декартово произведение, но предложение where
ограничивает порядок строк вместе для формирования результатов (на самом деле это не декартово произведение).
Я не тестировал этот SQL для этого, поскольку это одно из ограничений моей выбранной СУБД, и это правильно, я не верю это когда-либо было необходимо в правильно продуманной схеме. Поскольку SQL не гарантирует порядок, в котором он производит данные, соответствие может меняться каждый раз, когда вы выполняете запрос, если только у вас нет конкретного отношения или упорядочить по предложению
.
Я думаю, что идеальным вариантом было бы добавить столбец в обе таблицы, указывающие, каковы отношения. Если реальной взаимосвязи нет, то вам, вероятно, не стоит пытаться разместить их бок о бок с SQL.
Если вы просто хотите, чтобы они отображались бок о бок в отчете или на веб-странице (два примера ), правильный инструмент для этого - это то, что генерирует ваш отчет или веб-страницу, в сочетании с двумя независимыми SQL-запросами для получения двух несвязанных таблиц. Например, сетка из двух столбцов в BIRT (или Crystal или Jasper), каждая с отдельной таблицей данных, или таблица из двух столбцов HTML (или CSS), каждая с отдельной таблицей данных.
Я думаю, что идеальным вариантом было бы добавить столбец к обеим таблицам, определяющий, каковы отношения. Если реальной взаимосвязи нет, то вам, вероятно, не стоит пытаться разместить их рядом с SQL.
Если вы просто хотите, чтобы они отображались бок о бок в отчете или на веб-странице (два примера ), правильный инструмент для этого - это то, что генерирует ваш отчет или веб-страницу, в сочетании с двумя независимыми SQL-запросами для получения двух несвязанных таблиц. Например, сетка из двух столбцов в BIRT (или Crystal или Jasper), каждая с отдельной таблицей данных, или таблица из двух столбцов HTML (или CSS), каждая с отдельной таблицей данных.
Я думаю, что идеальным вариантом было бы добавить столбец к обеим таблицам, определяющий, каковы отношения. Если реальной взаимосвязи нет, то вам, вероятно, не стоит пытаться разместить их бок о бок с SQL.
Если вы просто хотите, чтобы они отображались бок о бок в отчете или на веб-странице (два примера ), правильный инструмент для этого - это то, что генерирует ваш отчет или веб-страницу, в сочетании с двумя независимыми SQL-запросами для получения двух несвязанных таблиц. Например, сетка из двух столбцов в BIRT (или Crystal или Jasper), каждая с отдельной таблицей данных, или таблица из двух столбцов HTML (или CSS), каждая с отдельной таблицей данных.
Если вы просто хотите, чтобы они отображались рядом в отчете или на веб-странице (два примера), правильный инструмент для этого - то, что генерирует ваш отчет или веб-страницу, в сочетании с двумя независимыми SQL-запросы для получения двух несвязанных таблиц. Например, сетка из двух столбцов в BIRT (или Crystal или Jasper), каждая с отдельной таблицей данных, или таблица из двух столбцов HTML (или CSS), каждая с отдельной таблицей данных.
Если вы просто хотите, чтобы они отображались рядом в отчете или на веб-странице (два примера), правильный инструмент для этого - то, что генерирует ваш отчет или веб-страницу, в сочетании с двумя независимыми SQL-запросы для получения двух несвязанных таблиц. Например, сетка из двух столбцов в BIRT (или Crystal или Jasper), каждая с отдельной таблицей данных, или таблица из двух столбцов HTML (или CSS), каждая с отдельной таблицей данных.
Чтобы получить осмысленное / полезное представление о двух таблицах, вам обычно необходимо определить поле идентификации из каждой таблицы, которое затем можно использовать в предложении ON в JOIN.
Затем на ваш взгляд:
SELECT T1.*, T2.* FROM T1 JOIN T2 ON T1.IDFIELD1 = T2.IDFIELD2
Вы упомянули, что поля не являются «общими», но хотя идентифицирующие поля могут иметь разные имена или даже не один и тот же тип данных, вы можете использовать функции convert / cast, чтобы объединить их каким-то образом.
Это очень странный запрос, и почти наверняка то, что вы никогда не захотите делать в реальном приложении, но с чисто академической точки зрения это интересная задача. В SQL Server 2005 вы можете использовать общие табличные выражения и функции row_number () и присоединиться к этому:
with OrderedFoos as (
select row_number() over (order by FooName) RowNum, *
from Foos (nolock)
),
OrderedBars as (
select row_number() over (order by BarName) RowNum, *
from Bars (nolock)
)
select *
from OrderedFoos f
full outer join OrderedBars u on u.RowNum = f.RowNum
Это работает, но это в высшей степени глупо, и я предлагаю его только как ответ «вики сообщества», потому что я действительно не рекомендую это.
Если в таблицах нет общих полей, то нет способа объединить данные в каком-либо значимом представлении. Скорее всего, вы получите представление, содержащее дублированные данные из обеих таблиц.
SELECT *
FROM table1, table2
Это объединит каждую строку в таблице 1 с таблицей 2 (декартово произведение), возвращая все столбцы.