Какова цель ограничения именования

Question

Какова цель именования ваших ограничений (уникальный, первичный ключ, внешний ключ)?

Скажем, у меня есть таблица, которая использует естественные ключи в качестве первичного ключа:

CREATE TABLE Order
(
    LoginName        VARCHAR(50)    NOT NULL,
    ProductName      VARCHAR(50)    NOT NULL,
    NumberOrdered    INT            NOT NULL,
    OrderDateTime    DATETIME       NOT NULL,
    PRIMARY KEY(LoginName, OrderDateTime)
);

Какие преимущества (если они есть) дает название моего ПК?

Например. Заменить:

    PRIMARY KEY(LoginName, OrderDateTime)

С:

    CONSTRAINT Order_PK PRIMARY KEY(LoginName, OrderDateTime)

Извините, если моя модель данных не самая лучшая, я новичок в этом!

Answer 1

Вот несколько довольно основных причин.

(1) Если запрос (вставка, обновление, удаление) нарушает ограничение, SQL сгенерирует сообщение об ошибке, которое будет содержать имя ограничения. Если имя ограничения является ясным и описательным, сообщение об ошибке будет легче понять; если имя ограничения является случайным именем, основанным на guid, это намного менее понятно. Частные вопросы для конечных пользователей, которые (хорошо, возможно) позвонят вам и спросят, что "FK__B__B_COL1__75435199" средства.

(2) Если в будущем нужно изменить ограничение (да, такое бывает), это очень трудно сделать, если вы не знаете, как оно называется. (ALTER TABLE MyTable drop CONSTRAINT um...) И если вы создаете более одного экземпляра базы данных "с нуля" и используете сгенерированные системой имена по умолчанию, никакие два имени никогда не будут совпадать.

(3) Если человек, которому приходится поддерживать ваш код (он же DBA), должен тратить много бессмысленного времени на рассмотрение дела (1) или дела (2) в 3 часа ночи в воскресенье, он вполне может определить, откуда пришел код, и иметь возможность реагировать соответствующим образом.

Answer 2

Чтобы определить ограничение в будущем (например, вы хотите удалить его в будущем), оно должно иметь уникальное имя. Если вы не укажете имя для него, ядро ​​базы данных, вероятно, назначит вам странное имя (например, содержащее случайные вещи для обеспечения уникальности).

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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

1. Мы можем быстро выявить и исправить любые ошибки.
2. Мы можем надежно изменить или снять ограничения.

Answer 7

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

Answer 8

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

Answer 9

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

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

Смотрите мой ответ о том, как сделать это с PostgreSQL и Java.