Как построить правильно архитектуру веб приложения под мою задачу?
Передо мной стоит не типичная задача по разработке некого saas решения по обработки заявок с сайтов, лидов, клиентов, задач и того подобное. Можно сказать это не большая CRM система, большими братьями можно назвать bitrix24, megaplan. В работе будут использоваться стандартные инструменты LAMP.
Возвращаясь к сути вопроса, мне нужно чтобы база данных под каждую компанию была своя, тем самым изолирована от остальных, в случаи если она накрывается или крадется это не имело последствий для остальных компаний. Программный код, дизайн и верстка будет соответственно общим.
Вопрос в том как мне подойти к созданию/изменению/разработке большое количество баз данных, где копать что читать?
Ошибка в общем программном коде и разные базы (или одна) - уже не важно.
Унесут все.
Простая защита - alias-ы:
ID-компании, логин1 и пароль1 (для кода/скриптов) => API (query-proxy) => DB-компании, host, логин2 и пароль2 (для базы)
На уровне API делаете централизованную проверку на "кривость" запросов и запускаете под другим пользователем, который кроме исполнения этого файла больше ничего не может.
Итого имеем: [web-server] => [query-proxy] => [db's]
Чтобы получить доступ к базе, нужно вначале получить доступ к просмотру информации в [query-proxy]. А это уже не так просто, особенно, если он в виде скомпилированного модуля.
Если вы изначально думаете, что базу могут украсть или она сломается - то в чем разница? Что у вас будет 100 баз, что одна. Любую украдут или любая сломается.
Поддерживать большое количество БД - не очень просто. Если это небольшая CRM-система - то зачем вам такие сложности?
Если логика вывода, верстки, кода одна - то проблем подсоединиться к определенной БД для серверных языков программирования не составит проблем.
Просто проект будет развиваться и хочется сразу начать делать правильно. Может получиться так что пользователь захочет перенести систему на свой сервер. А проблема у меня не в том как работать с несколькими базами а в том как вносить изменения. К примеру я захотел переименовать таблицу, как мне это сделать сразу в ста базах.
@frost18 о чем и речь. Вы решите, что вам нужно. Почему куча БД - это правильное решение? Зачем вы за него зацепились? Что вы понимаете под переносом системы? Переименовать таблицу - эта самая маленькая проблема, с которой вы можете столкнуться при работе с сотней БД :)
@frost18 начните делать по задачам. Мегаплан и битрикс сразу не стали тем, кем являются. Пока вы будете делать суперкар под ваши задачи, и он будет стоять в гараже - кто-то выйдет на раздолбанной инвалидке и будет на ней ездить, постепенно улучшая её. Я больше чем уверен, что "инвалидка" для старта - это стократ круче, чем неработающий, но офигенный облачный сервис с кучей баз данных, который никому не нужен.
При разработке сервиса nonzenon мы тоже столкнулись с такой проблемой. Несмотря на ежедневные резервные копии, мы делаем не только отдельную БД для каждой организации, но и отдельный сервер. Это тяжеловато, конечно, зато риск потерять всё и сразу сильно снижается.
