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

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

Пример:

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

Animal_Id (PK)  
Animal_Type  
Animal_Name

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

Animal_Id (PK)  
Tenant_Id (PK)  
Animal_Type  
Animal_Name

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


database security multi-tenant
person awright    schedule 22.03.2011    source источник
comment
Вы сказали, что я хотел бы сохранить Tenant_Id в большинстве моих таблиц в качестве меры безопасности, чтобы гарантировать, что данные не попадут в руки неправильного клиента. Как вы ожидаете, что столбец tenant_id предотвратит попадание данных в руки неправильного арендатора?   -  person Mike Sherrill 'Cat Recall'    schedule 22.03.2011
comment
@Catcall: путем фильтрации по tenant_id?   -  person Quassnoi    schedule 22.03.2011
comment
@Quassnoi: работает только в том случае, если у вас никогда, за время существования базы данных, не было более одного арендатора на единицу. Шансы невелики.   -  person Mike Sherrill 'Cat Recall'    schedule 23.03.2011
comment
@Catcall: цель мультитенантной базы данных - иметь одного арендатора на единицу.   -  person Quassnoi    schedule 23.03.2011

Ответы (3)


arrow_upward
5
arrow_downward

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

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

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

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

person Quassnoi    schedule 22.03.2011

arrow_upward
4
arrow_downward

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

person HLGEM    schedule 22.03.2011

arrow_upward
1
arrow_downward

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

person Justin Cave    schedule 22.03.2011
comment
Прохладный. Может, я слишком усложняю. Спасибо, парни. - person awright; 22.03.2011
comment
Почему мы не добавляем GUID в качестве идентификатора для каждой записи? вместо автоматически увеличиваемого идентификатора - person Murali Murugesan; 16.10.2012
comment
@Murali - Это, безусловно, вариант. Однако в целом создание GUID происходит медленнее, чем получение nextval из последовательности, и требуется больше места для хранения данных. Это также может усложнить поддержку системы - достаточно просто сказать кому-нибудь взглянуть на ANIMAL_ID 4227, если вы отслеживаете проблему в данных. Труднее отправить 32-символьное шестнадцатеричное представление 16-байтового значения RAW и убедиться, что кто-то другой смотрит на правильную строку. - person Justin Cave; 16.10.2012
comment
Спасибо, Джастин !. Можете ли вы посмотреть на мой вопрос stackoverflow.com/questions/12911357/ и, если возможно, добавьте свои предложения? Ваш вклад всегда полезен - person Murali Murugesan; 17.10.2012