Составные ключи в многопользовательской базе данных

Question

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

Пример:

В условиях одного арендатора у меня будет один первичный ключ:

Animal_Id (PK)  
Animal_Type  
Animal_Name  

В мультитенантных обстоятельствах я бы добавил еще один первичный ключ для Tenant_Id:

Animal_Id (PK)  
Tenant_Id (PK)  
Animal_Type  
Animal_Name  

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

Answer 1

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

Однако, у этого есть несколько побочных эффектов, которые вы можете или не можете видеть как недостатки:

• Возможно, вы можете связать две сущности от разных арендаторов в таблице связей многие-ко-многим, и ограничение FOREIGN KEY не помешает вам сделать это (как это было бы в случае, если tenant_id была частью PRIMARY KEY)
• Ваши пользователи могут оценить, сколько других арендаторов есть по идентификаторам
• Вам необходимо будет дополнительно присоединить таблицы сущностей к поискам, которые, возможно, могут быть выполнены только из таблиц ссылок «многие ко многим» (для проверки арендатора)

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

Answer 2

Если вы не повторяете другой идентификатор для каждого клиента (у вас может быть два или более animal_id = 1), нет реальной причины делать его составным ключом.Вы можете просто добавить поле.Это работает для нас.

Answer 3

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