Управление несколькими учетными записями и пользователями в SQL и активами, связанными с учетной записью

Question

Я создаю приложение, которое может иметь несколько пользователей из нескольких учетных записей. Например, учетной записью может быть компания ABC. Пользователи X, Y и Z являются членами этой учетной записи. Каждая учетная запись должна иметь свой отдельный экземпляр, чтобы, если компания ABC создала новый элемент БД, она должна быть видимой и управляемой компанией ABC. Мой вопрос заключается в следующем: должен ли я делать ссылку на явный внешний ключ для учетной записи в каждой отдельной таблице в моей БД? Например:

ТАБЛИЦА - СЧЕТА

ACCOUNT_ID | ACCOUNT_NAME 
1234  | Company ABC 

TABLE - СТР

PAGE_ID | PAGE_TITLE | ACCOUNT_ID 
987  | My Page | 1234 

ТАБЛИЦА - АКТИВ

ASSET_ID | ASSET_TITLE | ACCOUNT_ID 
4443  | My Asset | 1234 

ТАБЛИЦА - ГРУППЫ

GROUP_ID | GROUP_NAME | ACCOUNT_ID 
8888  | Admins  | 1234 

и т.д.?

Это кажется мне неправильным по какой-то причине, и я чувствую, что есть лучший способ, о котором я не думаю. У меня есть около 75 таблиц, которые мне нужно будет сделать для этого. Это правильно?

Answer 1

Мне пришлось иметь дело с этой ситуацией, и вполне вероятно, что вам придется включать столбец ACCOUNT_ID на многие (хотя и не обязательно все) ваши таблицы. Альтернативой является наличие отдельных баз данных для каждой учетной записи. Это может привести к проблемам обслуживания, так как вы должны обеспечить, чтобы все изменения DDL и DML были повсеместно применены. Это также потенциально может привести к проблемам с производительностью. Применение столбца к каждой таблице (немного) усложняет объединение запросов и просмотры, необходимые для данных, но объединения обычно являются низкими (или нет) затратами с точки зрения производительности и пространства. Единственное преимущество отдельных баз данных состоит в том, что это, скорее всего, более безопасное решение - кольцевое ограждение каждой учетной записи от всех остальных.

Я предложил, чтобы не все ваши таблицы нуждались в столбце учетной записи. Потребность в этом будет зависеть от путей доступа. - Например, у меня есть отношения sub/super type, выраженные в моих таблицах. Каждый подтип и каждый супер-тип имеют свою собственную таблицу. Доступ ко всем подтипам осуществляется только через супер-тип, поэтому супер-тип будет нуждаться в ссылке на ACCOUNTS, но подтипы не будут.

EDIT: My question и ответы и комментарии к нему, касающиеся этого типа конструкции вопрос привел к моей выше вывод.