SaaS-способы доступа к нескольким базам данных и механизмам аутентификации пользователей с главной базой данных
Я нахожусь в процессе создания приложения saas с основной базой данных для всех транзакций, а также базой пользователей и отдельными базами данных для каждого арендатора. Каждому арендатору присваивается уникальный поддомен, и на основании этого правильная база данных указывается на арендатора. Веб-приложение построено с использованием php, а MySQL используется для хранения данных.
У меня есть пара проблем, и для начала;
-
Когда пользователь посещает домашнюю страницу арендаторов (например, Sub.abc.com), будет доступна функция входа в систему. Так как пароль пользователя и база пользователей находятся в базе данных master, как я могу аутентифицировать пользователя? Это через отдельное соединение с базой данных для основной базы данных или через веб-интерфейс? Какой самый лучший способ?
-
Будут роли, созданные арендатором. Итак, предположим, что персонал для конкретного арендатора извлекается путем вызова веб-API, а роль сохраняется в базе данных арендатора вместе с идентификатором пользователя. Правильный ли это путь вперед, потому что нет прямого сопоставления внешнего ключа, а также после получения пользователей я должен сохранить их в базе данных клиентов или просто сохранить в памяти?
-
В случае, если владелец бизнеса хочет получить отчет о чем-то конкретном для каждой базы данных арендаторов, каков будет лучший способ получить все данные из каждой отдельной базы данных арендаторов?
-
Как мы можем зафиксировать использование базы данных каждого арендатора, хранение файлов и показать в супер-администратора?
Решение
как я могу аутентифицировать пользователя? Это через отдельное соединение с базой данных для основной базы данных или через веб-интерфейс? Какой самый лучший способ?
Будьте осторожны с вопросами «наилучшим образом» — это будет указывать на то, что этот вопрос будет не по теме, а основан на мнении.
Если ваше приложение имеет полностью закрытый исходный код (что я так себе представляю), то это не имеет значения. Вы можете получить доступ к своей основной базе данных напрямую, если хотите, потому что все ваши клиентские реализации будут частью вашего общего программного пакета.
Тем не менее, для масштабируемости и поддержки обслуживания, вероятно, лучше создать интерфейс API аутентификации и использовать его, чтобы вам не нужно было управлять компонентом подключения к базе данных вашего клиентского программного обеспечения.
…роль хранится в базе данных клиента вместе с идентификатором пользователя. Правильный ли это путь вперед, потому что нет прямого сопоставления внешнего ключа, а также после получения пользователей я должен сохранить их в базе данных клиентов или просто сохранить в памяти?
Это отлично. Пользователи являются общими для всех ваших реализаций, но роли являются уникальными для каждой клиентской реализации. Это указывает на то, что подход к нему является правильным, так как сначала вы проходите аутентификацию, а затем назначаете роль клиента пользователю, вошедшему в систему. Вы должны проверить это в своей локальной базе данных (очевидно), а затем назначить ее сеансу пользователя, чтобы он остается на время их посещения.
В случае, если владелец бизнеса хочет получить отчет о чем-то конкретном для каждой базы данных арендаторов, каков будет лучший способ получить все данные из каждой отдельной базы данных арендаторов?
Это слишком широко, чтобы ответить. Вы также должны быть здесь осторожны, потому что данные клиента могут не быть вашими для отчета!
Как мы можем зафиксировать использование базы данных каждого арендатора, хранение файлов и показать в супер-администратора?
Опять же, довольно широкий, но я предполагаю, что вы могли бы достичь чего-то подобного, запросив сервер MySQL для получения статистики базы данных для каждой клиентской базы данных и сделав то же самое для хранилища файлов, запросив сервер, на котором размещены файлы клиента.
Я надеюсь, что это полезно, пожалуйста, сузьте ваши вопросы немного больше, если вам нужна более конкретная помощь.
Другие решения
Будьте осторожны с вопросами «наилучшим образом» — это будет указывать на это
вопрос о том, чтобы быть не по теме, как на основе мнения.Если у вашего приложения полностью закрытый источник (который я себе представляю
есть), тогда это не имеет значения. Вы можете получить доступ к вашей основной базе данных
напрямую, если вы хотите, потому что все ваши клиентские реализации
будет частью вашего общего программного пакета.Это, как говорится, для масштабируемости и поддерживаемости это, вероятно,
лучше создать интерфейс API аутентификации и использовать его,
вам не нужно управлять компонентом подключения к базе данных вашего
клиентское программное обеспечение.
Согласовано. Понимаете, для таких сценариев очень сложно найти ответы, особенно по многопользовательскому типу.
Что вы подразумеваете под закрытым исходным кодом?
Если у меня могут быть API-интерфейсы аутентификации для извлечения данных из основной базы данных, как я могу разместить их таким образом, чтобы только доступ был предоставлен в приложении, а внешние стороны не могли получить к нему доступ? В дальнейшем нам нужно, чтобы сервисы также были доступны для внешних пользователей. В этом случае лучше разоблачить это отныне или поработать над отдельными сервисами позже? Какие из лучших библиотек веб-сервисов PHP вы знаете лучше, чем NuSOAP?
Это отлично. Пользователи являются общими для всех ваших реализаций, но
роли уникальны для каждой клиентской реализации. Это указывает на
что то, как вы приближаетесь к нему, является правильным в том, что вы аутентифицируете
затем назначьте роль клиента пользователю после входа в систему.
следует проверить это в вашей локальной базе данных (очевидно), а затем назначить
это к сеансу пользователя, так что он остается на время их
визит.
Это правильно! Пользователи являются общими для всех реализаций, и они хранятся в основной базе данных, а не в отдельных базах данных арендаторов. Под ролями, которые я имел в виду, для каждого приложения-арендатора клиент может создавать роли, которые находятся в приложении-арендаторе, такие как биллинговая единица, учетные записи, стойка регистрации и т. д. Таким образом, эти user_id и role_id хранятся в базе данных арендатора. Вот почему я спросил, так как user_id не отображается напрямую в пользовательскую таблицу главной базы данных, если все в порядке.
Это слишком широко, чтобы ответить. Вы также должны быть осторожны здесь, потому что
данные клиента не могут быть вашими для отчета!
А теперь давайте предположим, что супер-администратор хочет знать роли каждого арендатора. В таком случае, как мне получить данные из всех баз данных арендаторов? Используем ли мы для этого Views или поскольку мы используем mysql, как мне этого добиться?
Опять же, довольно широкий, но я предполагаю, что вы могли бы достичь чего-то вроде
это путем запроса сервера MySQL для статистики базы данных на каждом
клиентская база данных и сделать то же самое для хранения файлов, запрашивая
сервер, на котором размещены файлы клиента.
Очень сожалею об этом. Мы в основном хотим отслеживать использование баз данных арендаторов, чтобы увидеть, превышают ли они согласованное нами количество. Вот почему. Я надеюсь, что есть способ достичь этого.
Кроме того, для изображений сайта лучше хранить их на жестком диске или в базе данных в виде больших двоичных объектов? В конце дня нам нужно подумать о масштабируемости, а также о том, как изображения будут загружаться с меньшим потреблением полосы пропускания?