Веб-приложение PHP: вопрос о наилучшей практике проектирования баз данных mysql

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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