SQL не верен реляционной модели во многих отношениях. Результат запроса SQL не является отношением, поскольку он может содержать столбцы с дублирующимися именами, «анонимными» (безымянными) столбцами, дублирующимися строками, нулевыми значениями и т. Д. SQL не рассматривает таблицы как отношения, поскольку полагается на порядок столбцов и т. Д.
Идея, стоящая за NATURAL JOIN
в SQL, состоит в том, чтобы упростить процесс верности реляционной модели. Результат NATURAL JOIN
двух таблиц будет иметь дубликаты столбцов по имени, следовательно, нет анонимных столбцов. Аналогичным образом, UNION CORRESPONDING
и EXCEPT CORRESPONDING
предоставляются для решения зависимости SQL от упорядочения столбцов в устаревшем синтаксисе UNION
.
Однако, как и во всех методах программирования, требуется дисциплина, чтобы быть полезной. Одним из требований для успешного NATURAL JOIN
является постоянное именование столбцов, поскольку объединения подразумеваются для столбцов с одинаковыми именами (обидно, что синтаксис для переименования столбцов в SQL является многословным, но побочным эффектом является поощрение дисциплины при именовании столбцов в базовые таблицы и VIEW
s :)
Обратите внимание, что SQL NATURAL JOIN
является равноправным соединением **, однако это не является препятствием для полезности. Учтите, что если бы NATURAL JOIN
был единственным поддерживаемым типом соединения в SQL, он все равно был бы реляционно полным .
Хотя действительно верно, что любое NATURAL JOIN
может быть написано с использованием INNER JOIN
и проекции (SELECT
), также верно, что любое INNER JOIN
может быть написано с использованием произведения (CROSS JOIN
) и ограничения ( WHERE
); далее отметим, что NATURAL JOIN
между таблицами без общих имен столбцов даст тот же результат, что и CROSS JOIN
. Так что если вас интересуют только результаты, которые являются отношениями (а почему нет ?!), тогда NATURAL JOIN
- единственный тип соединения, который вам нужен. Конечно, это правда, что с точки зрения дизайна языка такие сокращения, как INNER JOIN
и CROSS JOIN
имеют свое значение, но также учитывают, что почти любой запрос SQL может быть написан 10 синтаксически различными, но семантически эквивалентными способами, и это то, что делает оптимизаторы SQL такими сложными для разработки.
Вот несколько примеров запросов (использующих обычную базу данных запчастей и поставщиков ), которые семантически эквивалентны:
SELECT *
FROM S NATURAL JOIN SP;
-- Must disambiguate and 'project away' duplicate SNO attribute
SELECT S.SNO, SNAME, STATUS, CITY, PNO, QTY
FROM S INNER JOIN SP
USING (SNO);
-- Alternative projection
SELECT S.*, PNO, QTY
FROM S INNER JOIN SP
ON S.SNO = SP.SNO;
-- Same columns, different order == equivalent?!
SELECT SP.*, S.SNAME, S.STATUS, S.CITY
FROM S INNER JOIN SP
ON S.SNO = SP.SNO;
-- 'Old school'
SELECT S.*, PNO, QTY
FROM S, SP
WHERE S.SNO = SP.SNO;
** Реляционное естественное соединение - не эквиджоин, это проекция одного. - philipxy