Должен ли я разделить данные между несколькими базами данных или сохранить их в одной?

Question

Я создаю многопользовательское / корпоративное веб-приложение на PHP и MySQL. Мне интересно узнать, как лучше всего структурировать мои базы данных.

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

В настоящее время база данных содержит 14 таблиц (для одной типовой компании).

Лучше ли поместить данные для всех компаний и их пользователей в одну базу данных и создать уникальный идентификатор компании для каждой из них?

или

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

Какие плюсы и минусы у каждого подхода?

Спасибо

Стивен

Answer 1

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

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

Answer 2

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

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

Answer 3

Multi-арендатор

Плюсы

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

Недостатки

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

однопользовательский

Достоинства

• Если у вас есть очень разные требования для разных арендаторов, может быть полезно несколько разных моделей баз данных. Это лучший вариант для использования одной настройки арендатора.
• Если вы выполняете небрежное кодирование, практически отсутствует риск утечки данных между арендаторами (арендатор A не сможет получить доступ к данным арендатора B ). Кроме того, если вы случайно уничтожите схему одного арендатора путем неудачного обновления, другие арендаторы останутся без изменений.
• Меньше кода SQL, когда вам не нужно принимать во внимание значения идентификатора клиента в ваших запросах

Недостатки

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

Answer 4

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