Одиночные V / s несколько баз данных

Я создал это веб-приложение (php & mysql), которое хранит информацию для различных организаций (в настоящее время около 20 клиентов).

В текущем сценарии информация о клиенте хранится в отдельных базах данных, поэтому имеется 20 клиентских баз данных и 1 основная база данных.

Одним из основных преимуществ здесь является то, что, поскольку каждая клиентская база данных изолирована, нумерация клиентских артефактов (отчетов, аудитов) и т. Д. Упорядочена; давая нашим клиентам чувство безопасности.

Каждая БД имеет примерно 15 таблиц, и большинство строк в таблице составляют около 2000. Ожидается, что это будет максимум до 5000 записей.

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

Мы заключили соглашение о совместном хостинге, и наш провайдер предоставляет нам ограниченное количество. баз данных; и вот что заставило меня задуматься о централизации базы данных; так что ВСЕ данные клиента могут быть сохранены в базе данных master.

Конечно, возникают некоторые важные проблемы:

а. Сохранение последовательности артефактов (это можно устранить путем создания дополнительного ссылочного ключа) b. Скорость и производительность (в этом случае я могу создавать индексы, чтобы ускорить процесс) c. Безопасность: это будет управляться как каждый запрос, который выбирает информацию о клиенте. также будет отслеживать их client_id

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

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

Спасибо за ваш совет.

Есть наследственные риски и выгоды для обеих систем. Я работал в финансовой фирме, которая поддерживала примерно 40 клиентов (национальные банки) на 1 базе данных. Затем мы приобрели другую компанию, которая продала подобное программное обеспечение и имела 1 базу данных на клиента. Наконец, компания обанкротилась, и нам пришлось экспортировать все пользовательские данные. Вот с кем я работал и нашел:

Профи Единой БД:

1. Обновления программного обеспечения и исправления ошибок проще.
2. Легко управлять и сообщать обо всех данных клиента.
3. Обновление данных становится проще.
4. Легко создать модульную функциональность, которую хочет 1 клиент, отключите ее для других клиентов, а затем включите ее, когда они захотят в будущем.

Минусы Одиночной БД:

1. Целостность данных. У нас было 2 или 3 случая, когда пользователи одного банка видели данные другого банка. Это был кошмар. Тем более, что пользователями сайта были не только сотрудники банка, но и действительные счета клиентов банка! Это, безусловно, самая большая проблема с 1 базой данных
2. Экспорт данных клиента. Когда нам приходилось это делать, это обычно не имело большого значения. В итоге получается 1 таблица, в которой есть все клиенты, и вы отключаете эту таблицу, чтобы получить данные, специфичные для вашего клиента.

Плюсы нескольких БД:

1. Нет никакого беспокойства о кросс-клиентском загрязнении данных или нарушениях
2. Экспортировать данные клиентов очень просто.

Против нескольких БД:

1. Обновления и исправления ошибок - это был настоящий кошмар. Когда у вас есть 20 клиентов в 20 разных базах данных, вы быстро сталкиваетесь со случаем, когда один клиент хочет исправить ошибку, а другой думает, что ошибка является функцией, или не хочет рисковать обновлением. Кроме того, у вас будут случаи, когда 1 клиент хочет улучшения с изменением игры, а другие - нет. Когда это произойдет, ваши базы данных начнут расходиться. Внезапно вам придется обновить клиентов 1-15 с 1 сценарием 16-19 с другим, и 20 с третьим. Мы увидели, что это стало такой проблемой, что исправление ошибки заняло бы в 15-20 раз больше для компании, которую мы приобрели, чем для нас, потому что они должны были выполнить все тесты для каждого клиента и иметь дело со специальным кодом каждого клиента. По сути, им нужен был новый человек поддержки для каждого нового клиента,
2. Управление БД - когда вы получаете большое количество клиентов, управление всеми базами данных становится настоящей проблемой. Вам, без сомнения, понадобится больше времени для администрирования.

В конце моя рекомендация, увидев и сделавшая и то, и другое - иметь «дисциплину»! Я думаю, что выбор multi-db немного лучше, потому что он защищает вас, но вы никогда не сможете позволить своим клиентам сделать выбор, который заставит вас добавить функциональность только к ним, или вы попадете на путь отказа.

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

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

Если вы хотите сравнить данные между клиентами, то вы должны сделать это отдельно.

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

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

Но кроме этого случая, я думаю, что несколько баз данных лучше.

Одно преимущество, которое не может быть важным, но может быть полезным, состоит в том, что каждый клиент получает свои собственные последовательные идентификаторы (вместо того, чтобы пропустить группу, потому что другой клиент добавил записи).

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

Сначала последовательность артефактов. Я предполагаю, что вы используете целочисленные первичные ключи, чтобы обеспечить это. На самом деле у вас должен быть отдельный столбец «номер артефакта». ПК должны быть ПК и ничего больше. Люди говорят о «естественных ключах» и тому подобное, и я съеживаюсь Всякий раз, когда вы полагаетесь на PK, чтобы быть больше, чем идентификатор, он возвращается, чтобы укусить вас. Если вы хотите узнать последовательность чего-либо, сохраните дату или порядковый номер.

Я думаю, что в вашем случае управление конфигурацией приведет вас к единой базе данных. Посмотрите, сколько времени вам потребуется на обслуживание и обновление баз данных. Какие расходы связаны с каждым выпуском программного обеспечения? Также подумайте о стоимости, когда вы получаете нового клиента и должны создать БД и настроить приложение для него. Все может быть автоматизировано, вопрос в том, будет ли это стоить, когда у вас будет 100 баз данных?

В дальнейшем легче масштабировать (разбиение на разделы, оборудование, разделение и т. Д.) Одну базу данных, чем сделать то же самое для 100 баз данных.

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

Чтобы добавить к доводам "за" / "против", перечисленным до сих пор:

Плюсы нескольких баз данных:

1. Проблемы с блокировкой исключены; у нас есть базы данных, где клиенты могут запускать DDL-изменения в некоторых таблицах. Для больших таблиц (> 2 м записей) это блокирует таблицу на значительное время. Единственные люди, которые находятся в невыгодном положении, - это их собственные пользователи, так что это приемлемо.

2. Гибкость - у некоторых клиентов есть конкретные пожелания относительно данных, которые они хотят хранить; мульти-базы данных позволили нам гибко изменять их базу данных, без необходимости загромождать модель данных для других клиентов.

Минусы:

1. Главный минус: присоединение к другим столам намного более обременительно. У нас есть основная база данных, которая содержит большинство метаданных. Пользователи клиентской базы данных не имеют доступа к этой базе данных, поэтому все объединения между таблицами в этой базе данных и клиентской базой обрабатываются в приложении, а не в базе данных. Вы можете решить эту проблему, предоставив клиентским пользователям доступ к основной базе данных, но затем приложение может / может снова утратить информацию.

Удачи в выборе!

Я знаю, что вы уже выбрали ответ, но похоже, что есть другое решение, которое не было предложено:

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

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Это своего рода лучшее из обоих миров.

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