Дизайн базы данных - одна база данных, несколько сайтов

Question

Я знаю, что этот вопрос задавался много раз прежде, но я не мог найти точный ответ для своего. Поэтому, пожалуйста, позвольте мне спросить это здесь.

Мы создали CMS для управления одним сайтом. Сейчас компания расширяется, и у нас есть еще пара сайтов с почти идентичной структурой ядра. В дальнейшем мы решили использовать одну базу данных для упрощения обслуживания.

У нас около 10 таблиц. Например, Страницы, Новости, Настройки (разные для каждого сайта), ...

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

Например,

PAGES:
PageID   |   Body   |   SiteID
1        | abc      |   1
2        | cde      |   1
3        | aafd     |   2
4        | gsgs     |   2
5        | feg      |   3

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

Я внимательно посмотрел на Мультитенантную архитектуру , но не знаю, как применить ее к CMS наших сайтов.

Как лучше всего справиться с этой ситуацией, пожалуйста, помогите. Любое просветление ценится.

Простой код

Answer 1

Недавно мы рассматривали различные стратегии для мультитенантной единой базы данных.

Если вы не хотите добавлять идентификатор сайта в свои таблицы, вы можете предоставить каждому арендатору собственную схему и наборстолы.У каждого арендатора может быть своя собственная строка соединения, которая обеспечивает доступ только к его схеме (вам, очевидно, потребуется переключить соединение во время выполнения (достаточно просто с EF и NH, если вы их используете).

Однако опциямы решили добавить дополнительный уровень в наше приложение, чтобы каждый компонент приложения (в вашем случае «Новости», «Страницы» и т. д.) был представлен как функция в базе данных.

Каждый сайт имеет свою коллекцию«экземпляры» функции, и данные, хранящиеся для каждой из этих функций (блог может содержать сообщения, теги, категории), имеют ссылку на экземпляр функции (не сайт).

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

Answer 2

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

Мы пробовали несколько вещей.

Мы поклонники «лучших практик», «нормализации базы данных», «шаблонов проектирования», но мы перестали использовать практический подход, а не теоретический.

У нас была одна или несколько баз данных для каждого сайта / компании, и у каждой таблицы базы данных был «site_id», и это работало.

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

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

Несколько сайтов плюс "site_id", работали хорошо.

Answer 3

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

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