Мультитенантные PHP SaaS-отдельные БД для каждого клиента или их группировка?

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

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

Варианты, которые я, кажется, имею в таблице, что касается данных системы хранения являются:

Вариант 1 - хранить все в 1 большой базе данных, и иметь поле "client_id" на таблицах, которые в нем нуждаются (там будет около 30 таблиц, к которым он будет применяться), и иметь таблицу "клиенты", хранящую их основные настройки, детали и т. д., а также домен для сопоставления с ними. Затем он просто устанавливает глобально доступную переменную, содержащую их индивидуальный идентификатор клиента - очевидно, мне придется изменить каждый запрос, чтобы проверить столбец client_id.

Вариант 2 - есть главная таблица с таблицами "Общие ссылки" и таблицей "клиенты". Затем есть "блоки" других баз данных, каждый из которых содержит, скажем, 10 клиентов. Клиент получит свои собственные таблицы базы данных с префиксом идентификатора клиента. Это добавляет немного безопасности, чтобы защитить от просмотра других клиентских данных, если что-то пошло не так.

Вариант 3 - точно такой же, как вариант 2, за исключением того, что у вас есть 1 база данных для каждого клиента, полностью изолируя их от других клиентов, и теоретически обеспечивая немного большую защиту, что если бы таблицы 1 клиента были взломаны или иным образом повреждены, это не повлияло бы ни на кого другого. Самый большой недостаток заключается в том, что при развертывании нового клиента необходимо настроить всю базу данных, пользователя и пароль и т. д. Может ли это также вызвать значительное количество накладных расходов, или это будет почти то же самое, как если бы у вас были все в одной базе данных?

Также несколько пунктов - некоторые из этих клиентов будут иметь 5000+ "клиентов" наряду со всеми деталями для этих клиентов-вот почему Вариант 1 может быть немного проблематичным - если у меня есть 100 клиентов, это может равняться более полумиллиону строк в 1 таблице.

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

(к вашему сведению, система основана на PHP с MySQL)