Есть ли ВСЕГДА "базовая таблица" в любом запросе к базе данных?

Question

Ладно, это слегка теоретически, так что было бы здорово, если бы объективный энтузиаст базы данных высказал свое мнение.

Ради аргумента давайте согласимся, что существует такая концепция, как «базовая таблица» по отношению к запросу, когда одна таблица формирует большую часть информации из набора результатов.Представьте себе запрос, в котором есть три отношения - TableA, TableB и TableC

Предположим, что TableA имеет кардинальное число 1 миллион записей, а TableC имеет 500 записей, а TableC имеет 10 000.

Скажем, запрос выглядит так:

SELECT A.Col1
     , A.Col2
     , A.Col3
     , A.Col4
     , A.Col5
FROM TableA A
 LEFT JOIN TableB B ON B.ID = A.TableBID
 LEFT JOIN TableC C ON C.ID = A.TableCID

Хорошо, ясно Таблица A - это базовое соотношение, приведенное выше.Это самая большая таблица, она управляет результирующим набором, соединяясь «от», и визуально столбцы находятся даже на «левой стороне» результирующего набора.(Левая сторона на самом деле была критерием для моего коллеги).

Теперь давайте предположим, что TableA снова имеет 1 миллион строк, TableB является таблицей «соединения» или «моста» и имеет примерно 500 000 строк и TableCимеет 1000000 строкИтак, предположим, что запрос является просто внешним объединением, чтобы получить все столбцы в TableA и TableC, где существует связь, как показано ниже ...

SELECT A.*
     , C.*
FROM TableC C
 FULL OUTER JOIN TableB B ON C.ID = B.TableAID
 FULL OUTER JOIN TableA A ON A.ID = B.TableCID

Хорошо, поэтому, учитывая последний запрос, кто-нибудь может сказать мне, что такое "base"отношение "есть?Я не думаю, что есть один, но надеялся на мнение другого человека базы данных.

Answer 1

Концепция «управляющей» таблицы - это действительно предположение о том, как СУБД должна выполнять запрос внутренне.Оптимизатор запросов на основе правил *1002* при отсутствии каких-либо предпочтений, связанных с индексами, может рассматривать порядок расположения таблиц и объединений в запросе как существенный, когда речь идет о выборе плана выполнения.В оптимизаторе , основанном на стоимости , порядок таблиц и объединений не имеет значения, поэтому ничего о структуре самого запроса не скажет, какая таблица будет прочитана первой или в каком порядке оцениваются условия объединения.

При концептуализации запроса может быть полезно иметь мысленный образ одной таблицы, являющейся отправной точкой для запроса, но я думаю, что ответ на этот вопрос должен быть отрицательным.Логически говоря, нет такого понятия, как стол для вождения.

Answer 2

Базовая таблица - это заданная именованная табличная переменная - таблица database .Вот и все.В выражении запроса его имя является листовым выражением, обозначающим его значение.«Заданная переменная таблицы» была бы более описательной.Запрос может использовать буквенную нотацию для таблицы.Было бы разумно, чтобы данная именованная табличная константа также называлась «базовой».Речь не идет о какой-то «основной» таблице.

---

Реляционная модель основана на таблице, содержащей строки, которые составляют истинное предложение (утверждение) из его (* 1008)* характеристика ) предикат (шаблон оператора, параметризованный именами столбцов).Мы даем строки базовой таблицы и получаем строки выражения запроса.

Выражение запроса, которое является именем базовой таблицы, поставляется с предикатом, заданным конструктором.

/* (person, liked) rows where [liker] likes [liked] */
/* (person, liked) rows where Likes(liker, liked) */
SELECT * FROM Likes

Выражение запроса, являющееся литералом таблицы, имеет определенный предикат в терминах столбцов, равных значениям.

/* (person) rows where
    person = 'Bob'
*/
SELECT * FROM (VALUES ('Bob')) dummy (person)

В противном случае выражение запроса имеет предикат, построенный из предикатов выражения составной таблицы в соответствии с оператором отношения.

• Каждый оператор алгебры соответствует определенному логическому оператору.
  NATURAL JOIN & AND
RESTRICTtheta & ANDtheta
UNION & OR
MINUS & AND NOT
PROJECTall butC & EXISTS C
etc

/* (person) rows where
    (FOR SOME liked, Likes(person, liked))
OR  person = 'Bob'
*/
    SELECT liker AS person
    FROM Likes
UNION
    VALUES ('Bob')

/* (person, liked) rows where
FOR SOME [values for] l1.*, l2.*,
        person = l1.liker AND liked = l2.liked
    AND Likes(l1.liker, l1.liked)
    AND Likes(l2.liker, l2.liked)
    AND l1.liked = l2.liker
    AND person = 'Bob'
    AND NOT Likes(l1.liked, 'Ed')
*/
Likes l1 INNER JOIN Likes l2
ON l1.liked = l2.liker
WHERE l1.liker = 'Bob'
AND NOT (l1.liked, 'Ed') IN (SELECT * FROM Likes)

Нет никакой разницы в том, как базовое, литеральное выражение или выражение запроса оператора используется при определении предиката содержащего выражения запроса.

IsЕсть ли эмпирическое правило для построения запроса SQL из понятного человеку описания?
Реляционная алгебра - перекодировать значения столбцов

Answer 3

Термин «базовая таблица» имеет определение и не имеет ничего общего с тем, что вы описываете.«Базовый стол» - это всего лишь «стол».То есть это не представление, это не табличная функция, это не результат запроса.Это то, что хранится в базе данных в виде явной таблицы.

То, что вы, кажется, понимаете, похоже, больше связано со стратегиями оптимизации.Я использовал похожую терминологию - в контексте оптимизации - для описания «движущей таблицы», к которой обращается оптимизатор.Цель этого состоит в том, чтобы различать разные планы выполнения.

Рассмотрим запрос:

from t1 join t2 using (col)

Существует несколько разных планов выполнения.Вот некоторые методы и то, что для них можно считать «управляющей таблицей» (если есть):

for each row in t1
    for each row in t2
         compare col
-->  t1 is the "driving table"

for each row in t2
    for each row in t1
        compare col
--> t2 is the "driving table"

for each row in t1
    look up t2 value using index on t2(col)
--> t1 is the "driving table"

sort t1 by col
sort t2 by col
compare the rows in the two sorted sets
--> no "driving table"

hash t1 by col
hash t2 by col
compare the hash maps
--> no "driving table"

Другими словами, «управляющая» таблица имеет мало общего со структурой запроса.Он основан на стратегиях оптимизации, используемых для запроса.Тем не менее, left join s и right join s ограничивают пути оптимизации.Таким образом, в случае вложенного цикла или поиска по индексу «первой» (или «последней») таблицей будет таблица управления.

Answer 4

Позвольте мне предложить перспективу, где базовая таблица является первой в предложении FROM (т.е. не является JOIN ed таблицей).В случае, когда оператор может быть одинаково записан с одной или другой таблицей в качестве базовой таблицы, мы бы сказали, что существует две (или более) базовых таблиц .

В вашем первом запросе базовая таблица равна TableA.Если вы инвертируете TableA и TableC в запросе, вы не гарантированно получите те же результаты из-за LEFT JOIN.

Во втором запросе, так как вы используете FULL JOIN sвсе 3 таблицы могут быть инвертированы без изменения результата, так что это действительно случай использования запроса, где все таблицы являются базовыми таблицами .