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

Question

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

TABLE - СЧЕТА

ACCOUNT_ID | ACCOUNT_NAME
1234       | Company ABC

TABLE - PAGES

PAGE_ID | PAGE_TITLE | ACCOUNT_ID
987     | My Page    | 1234

TABLE -АКТИВЫ

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, выраженные в моих таблицах.Каждый подтип и каждый супертип имеет свою собственную таблицу.Доступ ко всем подтипам возможен только через супертип, поэтому супертипу потребуется ссылка на АККАУНТЫ, но подтипы не будут.

РЕДАКТИРОВАНИЕ: Мой вопрос и ответы и комментарии к нему, касающиеся этого типа вопроса о конструкции, привели к моему заключению выше.