Несколько баз данных против одной базы данных

Question

Я смотрю на существующий сайт, и они используют отдельные базы данных. Кажется, базы данных настроены следующим образом:

• общие типы (user_type, language, age, etc)
• данные участника (регистрационная информация и логин)
• настройка сайта

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

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

Какие могут быть причины для создания отдельных баз данных? (Сайт на PHP и MySQL.)

Редактировать: Имена БД:

• sitename (фактическое название сайта) (общие типы)
• member (данные участника)
• siteconfig (конфигурация сайта)

Answer 1

Чисто предположение о том, что было в умах создателей:

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

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

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

Опять чистые спекуляции ...

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

Answer 2

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

Answer 3

Также чистое предположение: возможно, это было архитектурное решение для поддержки разделения интересов.

Answer 4

Если бы была веская причина для разбивки базы данных на несколько меньших, как эта, базы данных, вероятно, имели бы имена, такие как "hadronsupercolliderrawdata" и "googlebackup_2008". Такие имена, как «общие типы» и «данные о членах» указывают на то, что они были просто поражены глупостью.

Answer 5

@ Corey Trager : Хорошая идея, но вы, конечно, можете указать, какие таблицы резервировать, а также какую разницу будет иметь выбор только из некоторых при постоянном обновлении других таблиц?