Итак, моя компания говорит о создании платформы электронной коммерции, которая будет обслуживать множество разных клиентов.Каждый клиент будет выглядеть по-своему и иметь свой собственный набор пользователей, но код поддержки (т. Е. Службы администрирования, серверы аутентификации, службы проверки, возможно, страницы администратора и т. Д.), И некоторые пользователи будут совместно использоваться, поэтомуИсправление ошибки может быть применено ко всем сайтам одновременно, основной администратор может войти на все сайты.
Поскольку весь набор сайтов StackExchange (с довольно высоким трафиком) работает на небольшом количестве серверов (дваЯ верю) Интересно, что это может означать для обслуживания множества не связанных (но похожих) веб-сайтов через одно веб-приложение или даже одну базу данных.
Чтобы иметь одну базу данных, я предполагаю, что в каждой таблице будут столбцы, идентифицирующиекакой области принадлежит объект, и каждый вызов SQL будет фильтроваться по этому столбцу.Кажется, что это станет кошмаром обслуживания и (что для меня менее важно) адом БД.
Другой вариант, с одним веб-приложением, но несколькими базами данных, я полагаю, область может быть связана с конкретным источником данныхгде все не общие данные могут быть указаны.Затем, когда был сделан любой запрос, соответствующий источник данных мог быть загружен, и веб-приложение работало бы так, как если бы был только один источник.Это может иметь дополнительное преимущество, заключающееся в том, что его можно легко масштабировать по горизонтали, поскольку при необходимости может создаваться тот же веб-приложение, но другой набор областей и источников данных.Веб-сайты можно легко перенести на новые серверы, просто скопировав веб-приложение и переместив базу данных.
Мне интересно, какие еще есть возможности, а также конкретные примеры, если они там есть.
Примечание. Я говорю не о масштабируемости в масштабе Twitter, не об аппаратном обеспечении / языках / и т. Д., А о методологиях и шаблонах проектирования.