Почему позиционные запросы плохие?

Question

Я читаю книгу Си Джея Дейта SQL и Теория отношений:Как написать точный SQL-код, и он приводит доводы в пользу того, что позиционные запросы плохие — например, этот INSERT:

INSERT INTO t VALUES (1, 2, 3)

Вместо этого вам следует использовать запросы на основе атрибутов, подобные этому:

INSERT INTO t (one, two, three) VALUES (1, 2, 3)

Теперь я понимаю, что первый запрос не соответствует реляционной модели, поскольку кортежи (строки) представляют собой неупорядоченные наборы атрибутов (столбцов).У меня возникли проблемы с пониманием того, в чем заключается вред в первом запросе.Кто-нибудь может мне это объяснить?

Answer 1

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

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

Answer 2

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

Кроме того, это означает, что любой, кто читает первую версию, должен обратиться к схеме, чтобы выяснить, что означают значения.По общему признанию, это похоже на использование позиционных аргументов в большинстве языков программирования, но почему-то SQL в этом отношении немного отличается - я бы, конечно, понял вторую версию гораздо проще (при условии, что имена столбцов разумны).

Answer 3

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

Answer 4

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

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

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

Хотя вы не очень часто меняете структуру таблицы, добавление дополнительных полей в таблицу является довольно распространенным явлением.

Кроме того, второй запрос более удобочитаем.Вы можете определить из самого запроса, что означают значения, помещенные в запись.

Answer 5

Что-то, о чем еще не упоминалось, так это то, что у вас часто будет суррогатный ключ в качестве вашего ПК, с auto_increment (или что-то подобное), чтобы присвоить значение.В первом случае вам нужно было бы указать что - то есть — но какое значение вы можете указать, если оно не должно использоваться? NULL может быть вариантом, но это действительно не подходит, учитывая, что PK будет установлен в NOT NULL.

Но помимо этого, вся эта "привязанность к определенной схеме" является гораздо более важной причиной, ИМО.

Answer 6

SQL предоставляет вам синтаксис для указания имени столбца как для инструкций INSERT, так и для SELECT.Вы должны использовать это, потому что:

• Ваши запросы устойчивы к изменениям в порядке следования столбцов, так что обслуживание занимает меньше времени.
• Порядок столбцов лучше соответствует тому, как люди думают, поэтому он более удобочитаем.Более понятно думать о столбце как о столбце "Имя", а не как о 2-м столбце.

Answer 7

Я предпочитаю использовать синтаксис, подобный обновлению:

INSERT t SET one = 1 , two = 2 , three = 3

Который гораздо легче читать и поддерживать, чем оба примера.

Answer 8

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

Answer 9

Я собираюсь добавить еще одну вещь, второй запрос изначально менее подвержен ошибкам даже до изменения таблиц.Почему я это говорю?Поскольку с помощью формы seocnd вы можете (и должны при написании запроса) визуально проверить, действительно ли столбцы в таблице insert и данные в предложении values или предложении select расположены в правильном порядке для начала.В противном случае вы можете случайно ввести номер социального страхования в поле Гонорар и заплатить ораторам их SSN вместо суммы, которую они должны внести за выступление (пример выбран не случайно, за исключением того, что мы засекли его до того, как это произошло на самом деле, благодаря визуальной проверке!).