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

Question

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

1. Мне нужно создать еще одно поле (site_id) почти в каждой таблице и дублировать данные.
2. Мне нужно создать одну таблицу с информацией site_id для всех других полей из других таблиц.

У обеих идей есть огромные минусы. Есть идеи? Спасибо.

Answer 1

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

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

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

Я не фанат создания разных физических таблиц для одного и того же типа данных от разных клиентов. Это имеет ряд неблагоприятных последствий:

• Становится трудно создать согласованную объектную модель с помощью инструмента ORM
• Этот подход не подходит для большого числа клиентов - если у вас есть 70 000 клиентов, которые должны обслуживаться из одной базы данных, у вас будет 70 000 наборов таблиц.
• Имена таблиц должны генерироваться динамически для операторов SQL.

Answer 2

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

Для (очень надуманного) примера, если моя схема включает таблицу Customers, таблицу Invoices и таблицу Invoice Line Items, мне не нужны site_id во всех трех таблицах. Мне нужен только site_id в таблице Заказчика.

Answer 3

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

Answer 4

Я предпочитаю создавать таблицы сопоставлений там, где это необходимо. Подумайте, что Продукт может существовать для Сайта 1, Сайта 2 и т. Д. Информация о продукте не меняется на всех сайтах. Хотя цены на продукцию могут! В этом случае таблице цен могут понадобиться SiteID и ProductID, где ProductID может быть реплицирован для каждой записи на разных сайтах. Это можно сказать и о пользователях, за исключением того, что пользователи могут воспринимать это как «старшего брата». Поэтому, хотя это может сработать для клиентов, я обычно рекомендую, чтобы у клиентов были разные учетные записи на разных сайтах! Иногда то, что будет работать физически, не означает, что это будет работать логически. Поместите SiteID туда, где он вам нужен, а не просто поместите его везде. Имейте в виду, что вам может понадобиться этот SiteID за пределами того места, где это требуется вашему приложению ... подумайте и о автономных запросах. Необходимость сделать 5 объединений для фильтрации по SiteID будет отстойной! Поддерживать индексы лучше, чем искать фильтр!

Что касается горизонтального разбиения с помощью отдельных таблиц с похожими именами ... используйте SQL Server 2005 и выше. Он имеет функции для разделения, так что беспокойство о размере данных больше не является проблемой.

Answer 5

Я думаю, что одним из подходов, используемых Wordpress и Drupal, является добавление таблиц к имени с префиксом:

dom1_Customers
dom2_Customers

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