В настоящее время я участвую в дискуссии с коллегой о лучших методах разработки базы данных создаваемого веб-приложения PHP. Приложение предназначено для предприятий, и каждая компания, которая зарегистрируется, будет иметь несколько пользователей, использующих приложение.
Моя методология дизайна заключается в создании новой базы данных для каждой компании, которая подписывается. Таким образом, все из песочных, модульных и небольших. Философия моих коллег состоит в том, чтобы поместить всех в одну базу данных. Его аргумент заключается в том, что если у нас зарегистрировано 1000+ компаний, мы закончим работу с более 1000 баз данных. Не говоря уже о беспорядке, который делает Business Intelligence.
Для примера предположим, что приложение является системой ввода заказов. С отдельными базами данных размер таблицы может оставаться управляемым, даже если каждая компания выполняет более 100 заказов в день. В однопоточном приложении таблицы могут очень быстро меняться.
Есть ли лучшая практика для этого? Я пробовал охотиться по Интернету, но не имел большого успеха. Приветствуются ссылки, официальные документы и презентации.
Заранее спасибо,
The1Rob
Я поговорил с архитектором базы данных из wordpress.com, службы хостинга для WordPress. Он сказал, что они начали работу с одной базой данных, объединив всех клиентов. В конце концов, содержание одного блога на самом деле не так уж и много. Разумеется, одна база данных более управляема.
Это работало хорошо для них, пока они не получили сотни и тысячи клиентов, они поняли, что им нужно масштабировать , запускать несколько физических серверов и размещать подмножество своих клиентов на каждом сервере. Когда они добавят сервер, было бы легко перенести отдельных клиентов на новый сервер, но сложнее разделить данные в одной базе данных, принадлежащей блогу отдельного клиента.
По мере того, как клиенты приходят и уходят, а блоги некоторых клиентов имеют большую активность, в то время как другие становятся устаревшими, перебалансировка нескольких серверов становится еще более сложной задачей обслуживания. Также легче контролировать размер и активность для каждой отдельной базы данных.
Важным фактором является также создание резервной копии базы данных или восстановление одной базы данных, содержащей терабайты данных, по сравнению с отдельными резервными копиями баз данных и восстановлением нескольких мегабайт. Подумайте: клиент звонит и говорит, что их данные получили SNAFU'd из-за плохой записи данных, и не могли бы вы восстановить данные из вчерашней резервной копии? Как восстановить данные одного клиента, если все ваши клиенты будут иметь общую базу данных?
В конечном итоге они решили, что разделение на отдельную базу данных на одного клиента , хотя и сложное для управления, предложило им большую гибкость, и они повторно закрепили свой хостинг для этой модели.
Таким образом, хотя с точки зрения моделирования данных кажется правильным сделать, чтобы сохранить все в одной базе данных, некоторые задачи администрирования базы данных становятся проще, когда вы передаете определенную точку останова объема данных.
Я бы никогда не создал новую базу данных для каждой компании. Если вы хотите модульную конструкцию, вы можете создать ее с помощью таблиц и правильно подключенных первичных и вторичных ключей. Вот где я узнал о нормализации базы данных, и я уверен, что это поможет вам здесь.
Это метод, который я бы использовал. Статья SQL
Я должен согласиться с вашим сотрудником. Реляционные базы данных предназначены для обработки больших объемов данных, а номера, о которых вы говорите (1000+ компаний, несколько пользователей на компанию, более 100 заказов / день), находятся в пределах ожидаемых границ. Отдельные базы данных:
Если ваш сайт становится огромным, в конечном итоге вам может понадобиться распространить данные на нескольких серверах. С этим справитесь, когда это произойдет. Чтобы начать так, по соображениям производительности звучит как преждевременная оптимизация.
Я лично не занимался этой ситуацией, но я бы подумал, что если вы хотите заниматься бизнес-аналитикой, вы должны объединить данные в автономную базу данных, чтобы затем выполнить любой анализ.
Кроме того, хранение их в отдельных базах данных упрощает разбиение на серверы (что вам, вероятно, придется делать, если у вас есть 1000 клиентов), не прибегая к беспорядочным технологиям репликации.
У меня был подобный вопрос некоторое время назад и пришел к выводу, что одна база данных значительно более управляема. Прямо сейчас у нас есть несколько баз данных (около 10), и уже сейчас становится больно управлять, особенно когда мы обновляем код. Мы должны перенести каждую отдельную базу данных.
Поверхность заключается в том, что данные разделяются чисто. Из-за чувствительности наших данных, это хорошо, но это делает его немного сложнее не отставать.
Отдельная методология базы данных имеет очень большой прогресс по сравнению с другой:
+ Вы можете разбить его на более мелкие группы, эта архитектура масштабируется намного лучше.
+ Вы можете легко создавать автономные серверы.
Это зависит от того, насколько вероятны изменения ваших схем. Если им когда-либо придется измениться, сможете ли вы безопасно внести эти изменения в 1000 отдельных баз данных? Если проблема масштабируемости найдена с вашим дизайном, как вы собираетесь ее исправить для 1000 баз данных?
Мы запускаем бизнес SaaS (Software-as-a-Service) с большим количеством клиентов и решили сохранить всех клиентов в одной базе данных. Управление 1000-ю отдельными базами данных – это рабочий кошмар.
Вы должны быть очень усердными, создавая свою модель данных и бизнес-объекты / запросы отчетов, которые обращаются к ним. Один из подходов, который вы, возможно, захотите рассмотреть, – это переносить идентификатор компании в каждую таблицу и гарантировать, что каждое предложение WHERE включает идентификатор компании для текущего пользователя. Если вы используете уровень доступа к данным, вы можете обеспечить соблюдение этого условия.
По мере того, как вы становитесь крупнее, вы можете по-прежнему вертикально разделять, размещая группы компаний на каждом физическом сервере, например, первые 100 компаний на сервере A, следующих 100 компаний на сервере B.