Есть ли порядок в столбцах таблицы в RMDB?

Я узнал, что в таблице нет понятия порядка в терминах кортежей (например, строк), но согласно википедии "кортеж - это упорядоченный список элементов". Означает ли это, что атрибуты имеют порядок? Если да, почему они будут рассматриваться по-разному, нельзя ли добавить еще один столбец в таблицу (именно поэтому у кортежей нет порядка)?

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

3 ответа

Решение

Есть два вида кортежей, так сказать. Существует "чистая математика", и там действительно кортежи обычно определяются как "упорядоченные списки значений". Таким образом, в математических теориях имеет смысл говорить о "первом значении в кортеже" и тому подобное. Это может быть смысл или контекст, на который ссылается ваша статья в Википедии.

Язык Haskell поддерживает этот тип кортежа и, например, он также имеет оператор fst() для извлечения "первого" значения из такого кортежа.

Однако Кодд осознал, что это было бы крайне непрактично при применении этой математической концепции списков кортежей как упорядоченных к области управления данными. В управлении данными он хотел адресации значений по имени атрибута, а не по порядковому положению. Действительно, представьте себе разрушительные последствия, если "второй атрибут из пяти" будет удален из таблицы, и теперь все программы, которые обращаются к "третьему" и "четвертому" атрибуту этой же таблицы, теперь должны быть изобретены и адаптированы.

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

И затем, как указано в этом другом ответе, существует SQL и его кощунственные отклонения от теории отношений. В SQL упорядочение атрибутов в кортежах и заголовках имеет смысл, и последствия повсеместны. В декларациях FK соответствие соответствующих ссылочных и ссылочных атрибутов осуществляется по порядковому номеру, а не по имени. Другие случаи с СОЮЗАМИ и ИСКЛЮЧЕНИЕМ. Возьмем таблицу T, столбцы X и Y одного типа.

ВЫБЕРИТЕ X,Y ИЗ T СОЮЗА ВЫБЕРИТЕ Y,X ИЗ T

сам по себе недопустим, но стандарт предписывает, чтобы имена столбцов в результате определялись системой (!). Реализации, которые "делают разумную вещь" и отклоняются от этого, производя таблицу со столбцами с именами X и Y соответственно, затем сталкиваются со своими пользователями с последствием того, что первое выражение не идентично

ВЫБРАТЬ Y,X ИЗ T СОЮЗ ВЫБРАТЬ Y,X ИЗ T

(потому что порядок столбцов X,Y - это другой порядок, чем Y,X, и, следовательно, заголовки неравны, и, следовательно, таблицы неравны.)

ВЫБЕРИТЕ X,Y ОТ T, КРОМЕ ВЫБРАТЬ Y,X ОТ T

дает результаты, которые оставят многих начинающих пользователей SQL на некоторое время.

Операции модели реляционной базы данных, как ее обычно понимают и используют, конечно же, не зависят от порядка атрибутов в отношении. Атрибуты переменной отношения всегда можно идентифицировать по имени, а не по положению. Однако нотация, используемая в теории реляционных баз данных, не всегда определяет имена атрибутов (или типы атрибутов) и иногда подразумевает упорядоченные атрибуты. Это в первую очередь вопрос письменной записи, а не структура или поведение реляционной модели. В следующей ссылке есть еще несколько обсуждений этих разных "именованных" и "упорядоченных" перспектив. http://webdam.inria.fr/Alice/pdfs/Chapter-3.pdf

В ранних работах EFCodd по реляционной модели фактически была предложена реляционная система, поддерживающая как упорядоченные, так и неупорядоченные версии отношений одновременно. С тех пор эта идея, кажется, была забыта или проигнорирована даже самим Коддом. Это не является частью современной теории реляционных баз данных.

К сожалению, в SQL определенно существует концепция порядка столбцов. Это важная часть синтаксиса и семантики SQL, которую поддерживает каждая СУБД SQL для соответствия стандарту ISO SQL. SQL не является реляционным, и это лишь один из способов отличия его от реляционной модели. Неуклюжие различия между моделью SQL и реляционной вызывают определенную путаницу у студентов реляционной модели, которые также используют SQL.

Математические и философские аргументы в сторону, взгляните на это практически с некоторыми реальными примерами.

Предположим, вы пишете этот SQL:

      INSERT INTO mytable 
SELECT
  a1, a2, ... a99
FROM anothertable;

Предположим, что это прекрасно работает, потому что порядок, в котором SELECT возвращает 99 столбцов, одинаков при каждом запуске и соответствует порядку столбцов, необходимых для mytable.

Но предположим, что мне дали задание просмотреть этот код, написанный моим коллегой. Как проверить правильность порядка столбцов? Мне придется покопаться в других частях системы, где создается mytable, чтобы проверить, правильно ли расположены столбцы. Так что правильность этого SQL зависит от другого кода, возможно, в другом коде в далеких и неясных местах.

Случай 2: допустим, гипотетический список столбцов выглядит так:

      ...
a63,
apt_inspecties.buurtcode_dominant,
apt_inspecties.buurtnaam_dominant,
--
apt_inspecties.buurtnaam,
apt_inspecties.buurtcode,
--
apt_inspecties.wijknaam_dominant,
apt_inspecties.wijkcode_dominant,
--
apt_inspecties.wijknaam,
apt_inspecties.wijkcode,
--
apt_inspecties.stadsdeelnaam_dominant,
apt_inspecties.stadsdeelcode_dominant,
--
apt_inspecties.stadsdeelnaam,
apt_inspecties.stadsdeelcode,
--
apt_inspecties.ggwnaam_dominant,
apt_inspecties.ggwcode_dominant,
--
apt_inspecties.ggwnaam,
apt_inspecties.ggwcode,
a80,
a81,
...

Затем когда-нибудь найдется кто-то, кто захочет изменить порядок первых строк naam/code, чтобы получить список в более систематическом порядке с 8-кратным naam, чем порядок кода, например:

      a63,
apt_inspecties.buurtnaam_dominant,
apt_inspecties.buurtcode_dominant,

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

Очевидное решение состоит в том, чтобы ВСЕГДА практиковать защитное кодирование, например:

      INSERT INTO mytable(a1, ... a99)
SELECT a1...a99
FROM anothertable;

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

Случай 3:

Предположим, что mytable потерялся и его нужно создать заново, например, из резервной копии данных. И предположим, что он воссоздан с другим порядком атрибутов. Или кто-то выполняет команду ALTER TABLE для удаления одного атрибута, а затем другую команду ALTER TABLE для добавления этого атрибута обратно, тем самым изменяя порядок атрибутов.

Я полагаю, что все согласятся с тем, что результирующая таблица такая же, как и исходная таблица. Вы бы посмотрели на данные и увидели, что соотношение между a1 и a2 (и т. д.) такое же. Одинаковое количество рядов.

Если вы сделаете какой-либо запрос, например

      SELECT ai, aj FROM mytable;

вывод будет таким, каким вы ожидаете от исходной таблицы.

Однако приведенный выше SQL не удастся, поскольку он основан на одном конкретном неявном порядке атрибутов.

Заключение:

Для реляционной базы данных, такой как Oracle, Postgresql, MySql и т. д., порядок строк и атрибутов не имеет значения. Назовите атрибуты в вашем SQL, чтобы задать желаемый порядок атрибутов, и используйте предложение ORDER BY, чтобы принудительно упорядочить строки.

Это связано со строгой типизацией в языках программирования. Не всем это нравится, и некоторые современные языки не имеют строгой типизации, например javascript, python. Однако для написания более крупного кода очень важна строгая типизация, и тогда машинописный текст, похоже, заменяет (дополняет) javascript.

Другие вопросы по тегам