Таблица пользователей в отдельной БД

Question

Примечание: я не собираюсь это реализовывать, это скорее мысленный эксперимент.

Предположим, у меня было несколько служб, доступных через веб-интерфейс. Как минимум два из которых потребовали регистрации пользователя и некоторые данные в базе данных. Одна регистрация предоставит доступ ко всем услугам. Как Google (GMail, Google Docs и т. Д.).

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

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

Можно ли предположить, что «большие мальчики» используют только одну базу данных и загружают ее тоннами разных (и, возможно, совершенно не связанных) таблиц?

Answer 1

Если вы используете правильную СУБД, вы можете выбрать лучшую из двух стратегий. В PostgreSQL в «базе данных» вы можете иметь отдельные схемы. Служба аутентификации будет осуществлять доступ к единой схеме и предоставлять другим службам ключ, который используется в качестве ссылки для данных в других схемах. Вы по-прежнему можете иметь дело со всей базой данных как с единым целым, т. Е.

• запрос по схемам без использования dblink
• хранить личную информацию отдельно (схемы могут иметь отдельные разрешения для каждого пользователя для дополнительной защиты данных)
• СУБД управляет ограничениями внешнего ключа (я полагаю)
• согласованное (по данным) резервное копирование и восстановление

Вы получаете эти преимущества за счет более сложного DAL (может не поддерживаться вашей любимой средой DAL) и меньшей переносимости между СУБД.

Answer 2

Я хотел бы рассмотреть вопрос о наличии 1 хранилища пользователей / ролей с отдельной базой данных для служб.

Answer 3

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

Также вы можете рассмотреть меньшую базу данных, содержащую только общие пользовательские данные.

Answer 4

Я никогда не делал этого, но я думаю, что это будет зависеть от производительности. Если почти нет накладных расходов на создание отдельных баз данных, это может быть ответом. Создание отдельных БД также может упростить распределение БД по машинам.

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

Answer 5

Есть несколько стратегий.

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

Я бы порекомендовал начать с одной базы данных. Если ваша СУБД поддерживает это, я бы организовал компоненты согласно SCHEMA, которые позволили бы вам по крайней мере поддерживать логическое разделение по конструкции. Вы можете легче рефакторинг позже.

Во многих базах данных есть таблицы, которые можно считать не связанными. Иногда в системе у вас есть несколько сущностных сетей, которые почти не соединяются (иногда вообще не подключаются). Вы также можете использовать СХЕМЫ в этих случаях.

Answer 6

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