“Один пользователь - одна база данных” - правильно ли, и если нет, то почему?

#база_данных #безопасность #архитектура

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

Поэтому есть два вопроса:    


Насколько данный подход правильный / неправильный и как его возможно реализовать.
Если данный подход неправильный, как аргументировать это заказчику?


При этом нужно учитывать что у приложения клиент-серверная архитектура.
    

Ответы

Ответ 1

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

Явные плюсы:


Sql доступ конкретного клиента можно (я бы даже сказал нужно)
дополнительно ограничивать sql учеткой. 
Независимость клиентов друг
от друга. 
Независимость данных клиентов друг от друга.


Что не совсем ясно по вашему вопросу и надо будет учитывать:


Есть ли общая точка входа для сервисных операций? Она должна быть либо защищена от
клиентов, либо клиенты от неё.
Какая архитектура приложения - клиент-БД или клиент-сервер-БД? В первом случае отдельная
база на клиента выглядит обязательной, во втором - в зависимости от нагрузки и требований
клиентов.
Есть ли (нужна ли) у клиентов возможность обновления на разные версии программы?
Одна база на всех не даст вам такую возможность.


Можно найти ещё причин, надо смотреть по ситуации.