Стоит ли разнести данные в БД: на пользователя своя схема?

Question

[Сергей]

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

Сейчас подумываю о разделении данных как здесь:

Это необходимо для того, чтобы мы могли в случае чего восстановить данные конкретного пользователя не касаясь остальных.
Меня волнует такие вопросы:
1. Тяжело ли работать с такой структурой БД?
2. Легко ли в дальнейшем осуществлять миграции структуры данных по всем схемам
3. Может мне лучше создавать отдельную базу на пользователя?
4. Может быть вы что-то предложите?

Answer 1

[igruschkafox]

1. Тяжело ли работать с такой структурой БД?
- Да это будет геморрой, особенно в части замусоривание базы разными таблицами
но эксплуатировать легче (каждый пользователь видит только свои данные и с ними сам работает)

2. Легко ли в дальнейшем осуществлять миграции структуры данных по всем схемам
- Если встанет вопрос миграции структуры, то это решение может прибавить проблем при данной операции

3. Может мне лучше создавать отдельную базу на пользователя?
- ни в коем случае , плодить базы на сервере - которые неизвестно как будут эксплуатироваться - Очень плохой вариант (а если человек уволится - потом что делать с этой базой)

4. Может быть вы что-то предложите?
- Мне нравится вариант предложенный Sumor

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

Вообще то так майкрософтом и рекомендуется поступать

Answer 2

[mletov]

Вы под кажого пользователя планируете 3 таблицы заводить? Очень странный вариант.
Для восстановления данных проще хранимку написать, которая удаляет текущие данные по этому пользователю в этих таблицах и инсертит из нужного бэкапа

Answer 3

[Sumor]

Работает - не трогай.
А по сути, вопрос в том, что вас не устраивает в текущем хранении и насколько связаны данные разных пользователей.
Если данные пользователей тесно переплетены, то есть Products, Items связаны с несколькими пользователями одновременно, но может нет смысла так заморачиваться.
Если же данные пользователей наоборот разделены, то вы можете рассмотреть вопрос о создании под каждого пользователя своей БД. При заведении пользователя она будет создаваться, при удалении - удаляться, сохранение/восстановление/права - всё будет.
Если хотите поиграться схемами, то лучше использовать не таблицы, а представления. На каждого пользователя создать представления в своей схеме с отбором только его записей и выставлением прав.