PHP Web Application: вопрос о лучших практиках проектирования баз данных MySQL

Question

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

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

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

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

Заранее спасибо,

The1Rob

Answer 1

Я разговаривал с архитектором базы данных с wordpress.com, хостингом для WordPress. Он сказал, что они начали с одной базы данных, где все клиенты были вместе. В конце концов, содержание отдельного блога на самом деле не так уж много. Само собой разумеется, что одна база данных более управляема.

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

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

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

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

Итак, хотя с точки зрения моделирования данных кажется правильным сделать хранение всего в одной базе данных, некоторые задачи администрирования базы данных 1022 * становятся проще по мере прохождения определенной базы данных. точка останова объема данных.

Answer 2

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

Это метод, который я бы использовал. Статья SQL

Answer 3

Я должен был бы согласиться с вашим коллегой. Реляционные базы данных предназначены для обработки больших объемов данных, и цифры, о которых вы говорите (1000+ компаний, несколько пользователей на компанию, 100+ заказов в день), находятся в ожидаемых пределах. Отдельные базы данных означают:

• несколько соединений с базой данных в каждом скрипте (потеря памяти и скорости)
• обслуживание сложнее (системы БД, как правило, не предоставляют инструментов для работы с базами данных как группой), поэтому изменения схемы, резервные копии и подобные задачи будут более трудными
• сложнее выполнять запросы к данным от нескольких компаний

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

Answer 4

Мы ведем бизнес SaaS (Software-as-a-Service) с большим количеством клиентов и решили сохранить всех клиентов в одной базе данных. Управление тысячами отдельных баз данных - операционный кошмар.

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

По мере того, как вы становитесь большими, вы все еще можете разделять по вертикали, размещая группы компаний на каждом физическом сервере, например, первые 100 компаний на сервере A, следующие 100 компаний на сервере B.

Answer 5

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

Answer 6

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

Answer 7

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

Положительным моментом является то, что данные четко разделены. Из-за чувствительности наших данных это хорошо, но от этого немного усложняется.

Answer 8

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

Кроме того, хранение их в отдельных базах данных облегчает распределение по серверам (что, скорее всего, придется делать, если у вас более 1000 клиентов), не прибегая к грязным технологиям репликации.