Каковы наилучшие методы для разделения данных от пользователей

Question

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

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

Таким образом, мы пришли к этой модели данных:

Так что теперь вопрос: Как это лучше, чтобы отделить данные?
Это единственная альтернатива я вижу:

• SQL JOIN на всех соответствующих таблиц (Все таблицы, содержащие данные не должны не всегда вступать в организации) - Все запросы должны теперь добавить дополнительный присоединиться к организации , и если соединение не существует, нам нужно создать новый внешний ключ.

Но я чувствую дополнительное соединение (у нас есть около 20 таблиц, для которых требуется дополнительное соединение) довольно дорого.
Надеюсь, есть некоторые другие рекомендации или решения, которые мы можем рассмотреть.

PS: Это веб-приложение разработано с использованием Java/JSF/Seam (но я не знаю, если это уместно)

UPDATE

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

Все, что я хочу знать, это хорошее архитектурное решение (внутреннее соединение) или если мы должны сделать что-то еще (то есть: загрузить все общие данные и фильтровать в памяти вместо sql-соединения).

Answer 1

Вам действительно нужно понять разницу между уровнем стойкости и уровнем приложения.

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

Изменение дизайна базы данных должно производиться только по соображениям производительности, не для обеспечения безопасности, которое должно обрабатываться в приложении.

Answer 2

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

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

Как мета изменения для поддержки столбца организации, параметризуя хранимые процедуры будет достаточно тривиально:

select @organizationId = organizationId from User where User.id = @currentUserId 

select * from User where organizationId = @organizationId 

(в зависимости от Sql аромата вам нужно будет приложить некоторые объекты например, `` User , [ Пользователь] и т. Д.)

Answer 3

Я не вижу причины, что Организация должна быть «присоединена» вообще.

Если в ваших таблицах «данные» есть столбцы OrganizationID, вы можете найти «organizationID» от пользователя, а затем добавить это как условие для соединения.

EX:

select @OrganizationId = organizationId from User where User.id = @currentUserId 
select * from datatable a .... where .... AND a.organizationID = @organizationID 

См; нет соединения.

Что касается производительности, существуют разные типы соединений, и SQLServer позволяет вам намекать на тип соединения. Поэтому в некоторых случаях объединение слияния является лучшим, тогда как в чем-то подобном сценарии объединение в цикл будет лучшим. Не уверены, доступны ли эти варианты в MySQL.

Что касается всех ваших таблиц, нуждающихся в объединении или состоянии (см. Выше), есть логический ответ и ответ реализации. Ответ на выполнение зависит от вашего индексации. Если вы можете ограничить набор данных больше всего, добавив это условие, тогда вы выиграете. Но если соединение с другой таблицей, которая уже была отфильтрована, лучше справляется с сокращением строк, тогда условие будет бесполезным (или, в худшем случае, будет использовать неверный индекс). Предполагая, что у вас есть индексы в столбцах соединения и условия.

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