Веб-приложение PHP: вопрос о лучших практиках проектирования баз данных mysql
Я в настоящее время нахожусь в дебатах с коллегой о лучших практиках относительно проектирования баз данных веб-приложения PHP, которое мы создаем. Приложение разработано для компаний, и каждая компания, которая подписывается, будет иметь многочисленных пользователей, использующих приложение.
Моя методология проектирования состоит в том, чтобы создать новую базу данных для каждой компании, которая подписывается. Таким образом, все поигралось в песочнице, модульное, и маленькое. Моя философия коллег должна поместить всех в одну базу данных. Его аргумент - то, что, если мы имеем 1000 +, компании подписываются, мы волнуем с 1 000 + базы данных для контакта с. Не говоря уже о путанице, которой становится занимающаяся бизнесом Аналитика.
Ради примера предположите, что приложение является системой записи порядка. С отдельными базами данных размер таблицы может остаться управляемым, даже если каждая компания делает 100 +, заказывает день. В приложении единственного блока таблицы могут стать очень большими очень быстро.
Существует ли лучшая практика для этого? Я пытался искать вокруг сети, но не имел большого успеха. Ссылки, технические описания и приветствующиеся презентации.
Заранее спасибо,
The1Rob
8 ответов
Я разговаривал с архитектором базы данных из wordpress.com, службы хостинга для WordPress. Он сказал, что они начали с одной базы данных, в которой размещались все клиенты вместе. В конце концов, содержания одного блога на самом деле не так уж и много. Само собой разумеется, что единая база данных более управляема.
Это хорошо работало для них, пока у них не появились сотни и тысячи клиентов, они поняли, что им нужно горизонтально , запустить несколько физических серверов и разместить подмножество своих клиентов на каждом сервере. Когда они добавят сервер, будет легко перенести отдельных клиентов на новый сервер, но сложнее разделить данные в единой базе данных, которая принадлежит блогу отдельного клиента.
По мере того, как клиенты приходят и уходят, а в блогах одних клиентов наблюдается большой объем активности, в то время как другие становятся устаревшими, изменение баланса между несколькими серверами становится еще более сложной задачей обслуживания. Также проще отслеживать размер и активность каждой отдельной базы данных.
Подобным образом создание резервной копии базы данных или восстановления одной базы данных, содержащей террабайты данных, по сравнению с резервным копированием отдельных баз данных и восстановлением по несколько мегабайт каждое, является важным фактором. Подумайте: звонит клиент и говорит, что его данные попали в SNAFU из-за некорректного ввода данных, и не могли бы вы восстановить данные из вчерашней резервной копии? Как бы вы восстановили данные одного клиента, если бы все ваши клиенты использовали одну базу данных?
В конце концов они решили, что разделение на отдельную базу данных для каждого клиента , хотя и сложно в управлении, предлагает им большая гибкость, и они изменили архитектуру своих хостинговых услуг в соответствии с этой моделью.
Таким образом, хотя с точки зрения моделирования данных кажется правильным делать все в одной базе данных, некоторые администрирование базы данных задачи становятся проще по мере прохождения определенного точка останова объема данных.
Я должен согласиться с вашим коллегой. Реляционные базы данных предназначены для работы с большими объемами данных, а цифры, о которых вы говорите (1000+ компаний, несколько пользователей на компанию, 100+ заказов/день), вполне укладываются в ожидаемые рамки. Отдельные базы данных означают:
- соединения с несколькими базами данных в каждом скрипте (уменьшение памяти и скорости)
- обслуживание сложнее (системы БД обычно не предоставляют инструментов для работы с базами данных как группой), поэтому изменения схемы, резервное копирование и подобные задачи будут сложнее
- запускать запросы на данные от нескольких компаний
Если ваш сайт станет огромным, вам, в конечном счете, может понадобиться распределить ваши данные между несколькими серверами. Смиритесь с этим, когда это произойдет. Начинать таким образом по причинам производительности звучит как преждевременная оптимизация.
Я бы никогда не создал новую базу данных для каждой компании. Если вы хотите модульную конструкцию, вы можете создать ее, используя таблицы и правильно подключенные первичный и вторичный ключи. Здесь я узнал о нормализации базы данных и уверен, что это вам поможет.
Этот метод я бы использовал. SQL article
Отдельная методология базы данных имеет очень большой прогресс по сравнению с другой:
.
+ Можно разбить ее на более мелкие группы, эта архитектура масштабируется гораздо лучше.
+ Вы можете сделать автономные серверы простым способом.
Это зависит от того, насколько вероятны изменения ваших схем. Если они когда-нибудь изменятся, сможете ли вы безопасно внести эти изменения в 1000 отдельных баз данных? Если с вашей схемой возникнет проблема масштабируемости, как вы собираетесь ее решать для 1000 баз данных?
.Я лично не сталкивался с этой ситуацией, но думаю, что если вы хотите заниматься бизнес-аналитикой, вам следует агрегировать данные в автономную базу данных, чтобы затем можно было выполнить любой анализ. хочу дальше.
Кроме того, их хранение в отдельных базах данных упрощает разделение между серверами (что вам, вероятно, придется сделать, если у вас более 1000 клиентов), не прибегая к беспорядочным технологиям репликации.
Некоторое время назад у меня возник аналогичный вопрос, и я пришел к выводу, что единая база данных значительно более управляема. Прямо сейчас у нас есть несколько баз данных (около 10), и это уже становится проблемой, особенно когда мы обновляем код. Мы должны перенести каждую базу данных.
Положительным моментом является то, что данные разделены чисто. Из-за чувствительности наших данных это хорошо, но уследить за ними немного сложнее.
Мы ведем бизнес SaaS (программное обеспечение как услуга) с большим количеством клиентов и решили хранить всех клиентов в одной базе данных. Управление тысячами отдельных баз данных - это операционный кошмар.
Вы должны быть очень старательными, создавая свою модель данных и бизнес-объекты / запросы отчетов, которые обращаются к ним. Один из подходов, который вы можете рассмотреть, - это переносить идентификатор компании в каждую таблицу и гарантировать, что каждое предложение WHERE включает идентификатор компании для текущего пользователя, вошедшего в систему. Если вы используете уровень доступа к данным, вы можете обеспечить соблюдение этого условия там.
По мере роста вы все еще можете вертикально разделить, разместив группы компаний на каждом физическом сервере, например первые 100 компаний на сервере A, следующие 100 компаний на сервере B.