Съставни ключове в база данни с множество клиенти

Проектирам база данни за чисто многонаемане (една база данни, една схема) и бих искал да запазя 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

Освен ако не повтаряте другия id на клиент (можете да имате два или повече 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