Как обеспечить уникальность во многих отношениях?

Question

У пользователей много ролей, в роли много пользователей.

В USERS_ROLES таблице, имеют 3 колонки: USERS_ROLES_ID, USER_ID, ROLE_ID

Обычно USERS_ROLES_ID просто последовательно генерируется. Кто-то сказал мне, что он должен гарантировать, что user_id и role_id cross product уникальны, поэтому первичный ключ USERS_ROLES_ID действительно должен быть какой-то комбинацией USER_ID и ROLE_ID. Как это делается, как правило? (например, USER_ID * (здесь большое число) + ROLE_ID)? Каждый пример, который я мог найти, использует наивное последовательное формирование первичного ключа таблицы соединений «многие-ко-многим».

Answer 1

Последовательный сгенерированный первичный ключ USERS_ROLE_ID не гарантирует уникальную комбинацию USER_ID и ROLE_ID. Добавление уникального индекса в (USER_ID, ROLE_ID) будет.

Answer 2

Gerrat is right. Я нашел полный ответ здесь: http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

Create table CustomerProducts 
(
    Customer_ProductID int identity primary key, 
    CustomerID int references Customers(CustomerID) not null, 
    ProductID int references Products(ProductID) not null, 
    OrderLimit int not null 
) 

Это то, что я вижу в возможно большинство из баз данных, которые я работал с на протяжении многих лет. Причина для разработки таблицы таким образом? Честно говоря, я не знаю! Я могу только предположить, что из-за недостатка понимания, что такое первичный ключ таблицы, и , это может быть нечто, отличное от идентификатора, и что оно может быть , состоящее из более чем одного столбца. Как я уже говорил, кажется, , что многие архитекторы баз данных просто не знают об этом факте.

Рассмотрим вместо следующей конструкции:

Create table CustomerProducts (
    CustomerID int references Customers(CustomerID) not null, 
    ProductID int references Products(ProductID) not null, 
    OrderLimit int not null, 
    Primary key (CustomerID, ProductID)) 

Заметьте здесь, что мы устранили столбец идентификаторов, и имеют вместо определен композит (мульти-колонки) первичный ключ в качестве комбинации CustomerID и ProductID колонны. Поэтому мы делаем не нужно создавать дополнительные уникальные ограничения. У нас также нет нужен дополнительный столбец, который действительно не имеет никакой цели. Мы не только упростили нашу модель данных физически, но и сделали ее более логически обоснованной, а первичный ключ этой таблицы точно объясняет, что именно эта таблица моделирует: отношение идентификатора CustomerID к идентификатору продукта .