Вам придется нести со мной здесь, чтобы, возможно, немного исправить некоторые термины, поскольку я даже не знал, что это попало во все «многопользовательское» программное обеспечение как категорию обслуживания, но здесь оно и есть.
Я разработал систему членства (в PHP) для клиента. Теперь мы рассматриваем его как полностью размещенное решение для наших других клиентов, предоставляя субдомен (или даже собственный домен).
Параметры, которые, как мне кажется, имеют на столе, касается хранения данных:
Вариант 1 – Храните все в одной большой базе данных и используйте поле «client_id» для таблиц, которые ему нужны (около 30 таблиц, к которым оно относится) и имеют таблицу «клиентов», хранящую их основные настройки, подробности , и т. д. и домен для их сопоставления. Затем это просто устанавливает глобально доступную переменную, содержащую их индивидуальный идентификатор клиента – я, очевидно, должен будет изменить каждый отдельный запрос, чтобы проверить столбец client_id.
Вариант 2 – введите основную таблицу с таблицами «общая ссылка» и таблицей «клиенты». Затем есть «блоки» других баз данных, каждая из которых содержит, скажем, 10 клиентов. Клиент получит свои собственные таблицы базы данных с префиксом их идентификатора клиента. Это добавляет немного защиты для защиты от просмотра других данных клиента, если что-то пошло не так.
Вариант 3 – Точно так же, как вариант 2, за исключением того, что у вас есть 1 база данных для каждого клиента, полностью изолируя их от других клиентов и теоретически предоставляя немного больше защиты, если бы 1 клиентская таблица была взломана или повреждена иным образом, затрагивают кого-то еще. Самый большой недостаток заключается в том, что при развертывании нового клиента необходимо создать всю базу данных, пользователя и пароль и т. Д. Может ли это также вызвать слишком много накладных расходов, или это будет почти так же, как если бы у вас были все в одном база данных?
Несколько пунктов – некоторые из этих клиентов будут иметь 5000+ клиентов вместе со всеми подробностями для этих клиентов – вот почему вариант 1 может быть немного проблемой – если у меня есть 100 клиентов, которые могут равняться более полумиллиона строк в 1 таблице.
Правильно ли я считаю, что вариант 3 – лучший способ пойти в ситуации, когда ключом является безопасность данных клиента (и информации о платежах). Из рекомендаций, которые у меня были, несколько человек сказали, что идут с вариантом 1, потому что «его легче», однако я действительно этого не вижу. Я рассматриваю это как потенциальное узкое место в очереди, так как я уверен, что могу перемещать клиентов намного проще, если у них есть своя база данных.
(FYI. Система основана на PHP на базе MySQL)
Вариант 3 является наиболее масштабируемым. Хотя сначала это может показаться более сложным, оно может быть полностью автоматизировано и избавит вас от головных болей в будущем. Вы также можете масштабировать более эффективно, имея клиентские базы данных на нескольких серверах для повышения производительности.
Я согласен с Ozzy – я сделал это для онлайн-продукта базы данных. У нас была одна основная база данных, в которой в основном была прославленная таблица пользователей. У каждого клиента была своя база данных. Что было здорово в этом, так это то, что я мог перемещать одну базу данных клиентов с сервера A на сервер B легко [mysql] и мог делать это с помощью средств командной строки в крайнем случае. Кроме того, выполнение обслуживания на больших таблицах, сброс / добавление индексов может действительно испортить ваше приложение, особенно если, скажем, добавление индекса блокирует таблицу [mysql]. Это затрагивает всех. С, по-видимому, меньшими базами данных, вы более невосприимчивы к этому и имеете больше возможностей, когда вам нужно развертывать изменения уровня схемы. Мне просто нравится гибкость.
Когда много лет назад я разработал Innomatic , платформу с открытым исходным кодом для создания SaaS-приложений на PHP, я выбрал третий вариант: многопользовательский код и отдельные базы данных арендаторов .
По моему опыту, это наиболее масштабируемый вариант, но ему также нужен набор сценариев для распространения изменений при обновлении кода, схем БД, предоставлении приложений арендатору и т. Д.
Поэтому многие мои усилия были направлены на создание компонентного, расширяемого движка для полной автоматизации всех этих задач и минимизации системного администрирования. Я настоятельно рекомендую построить такую архитектуру, если вы хотите принять третий вариант.