Могут ли быть ограничения с тем же именем в БД?

Это следующий вопрос из того, что я спросил здесь.

Могут ли ограничения в БД иметь одно и то же имя?

Скажем, у меня есть:

CREATE TABLE Employer
(
    EmployerCode    VARCHAR(20)    PRIMARY KEY,
    Address         VARCHAR(100)   NULL
)


CREATE TABLE Employee
(
    EmployeeID      INT            PRIMARY KEY,
    EmployerCode    VARCHAR(20)    NOT NULL,
    CONSTRAINT employer_code_fk FOREIGN KEY (EmployerCode) REFERENCES Employer
)


CREATE TABLE BankAccount
(
    BankAccountID   INT            PRIMARY KEY,
    EmployerCode    VARCHAR(20)    NOT NULL,
    Amount          MONEY          NOT NULL,
    CONSTRAINT employer_code_fk FOREIGN KEY (EmployerCode) REFERENCES Employer
)

Допустимо ли это? Это зависит от СУБД (я на SQL Server 2005)? Если это недопустимо, есть ли у кого-нибудь какие-либо предложения по работе с ним?

Ответы

Ответ 1

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

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

CREATE TABLE BankAccount
(
    BankAccountID   INT            PRIMARY KEY,
    EmployerCode    VARCHAR(20)    NOT NULL,
    Amount          MONEY          NOT NULL,
    CONSTRAINT FK_BankAccount_Employer 
        FOREIGN KEY (EmployerCode) REFERENCES Employer
)

В основном мы используем "FK_" (дочерняя таблица) _ (родительская таблица) "для обозначения ограничений и вполне довольны этим соглашением об именах.

Информация из MSDN

Эти имена ограничений должны быть уникальными для схемы (т.е. две разные схемы в одной базе данных могут содержать ограничение с тем же именем) явно не документированы. Скорее вам нужно предположить, что идентификаторы объектов базы данных должны быть уникальными в пределах содержащейся схемы, если не указано иное. Таким образом, имя ограничения определено как:

Является ли имя ограничения. Имена ограничений должны соответствовать правилам для идентификаторов, за исключением того, что имя не может начинаться с знака числа (#). Если имя constraint_name не указано, для ограничения назначается системное имя.

Сравните это с названием index:

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

который явно сужает область действия идентификатора.

Ответ 2

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

Ответ для MS SQL Server - да, но только до тех пор, пока ограничения находятся в разных схемах. Имена ограничений должны быть уникальными в рамках схемы.

Ответ 3

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

Затем я прочитал о ограничении SQL-99 ASSERTION, который похож на контрольное ограничение, но существует отдельно от какой-либо отдельной таблицы. Условия, объявленные в утверждении, должны выполняться последовательно, как и любое другое ограничение, но утверждение может ссылаться на несколько таблиц.

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

Ответ 4

Зависит ли он от СУБД (я на SQL Server 2005)?

Да, очевидно, это зависит от СУБД.

Другие ответы говорят, что это не разрешено, но у меня есть база данных MS SQL CE ( "Compact Edition" ), в которой я случайно успешно создал два противопоказания FK в двух таблицах с тем же именем contraint.

Ответ 5

Хорошей практикой является создание имен индексов и ограничений с указанием имени таблицы в начале. Там 2 подхода, с индексом/ограничением типа в начале или в конце), например.

UQ_TableName_FieldName

или

TableName_FieldName_UQ

Имена внешних ключей также должны содержать имена ссылочной таблицы/полей.

Одним из хороших соглашений об именах является предоставление имен таблиц в виде FullName_3LetterUniqueAlias, например.

Employers_EMR
Employees_EMP
BankAccounts_BNA
Banks_BNK

Это дает вам возможность использовать "предопределенные" псевдонимы в запросах, которые улучшают читаемость, а также упрощают "Именование внешних ключей", например:

EMPEMR_EmployerCode_FK
BNKEMR_EmployerCode_FK

Ответ 6

Это зависит от СУБД.

Например, в PostgreSQL ответ да:

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

Источник: https://www.postgresql.org/docs/current/static/sql-set-constraints.html

Я видел, что имена ограничений внешнего ключа равны на 2 разных таблицах в рамках одной и той же схемы.