Несколько экземпляров приложения в одной базе данных - PullRequest
5 голосов
/ 26 ноября 2009

Я пишу приложение, которое я собираюсь предоставить как услугу, а также как отдельное приложение. Он написан на Zend Framework и использует MySQL.

При предоставлении его в качестве услуги я хочу, чтобы пользователи регистрировались на моем сайте и имели субдомены, например customer1.mysite.com, customer2.mysite.com.

Я хочу, чтобы все было в одной базе данных, а не для создания новой базы данных для каждого пользователя.

Но теперь мне интересно, как это сделать лучше. Я придумал два решения: 1. Укажите идентификатор пользователя в каждой таблице и просто добавьте его в предложение WHERE при каждом запросе к базе данных. 2. Создайте заново таблицы с уникальным префиксом, например, «customer1_tablename», «customer2_tablename».

Какой подход лучше? Плюсы и минусы? Есть ли другой способ разделения пользователей в одной базе данных?

Леонтий

Ответы [ 4 ]

3 голосов
/ 26 ноября 2009

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

Если таблицы становятся действительно большими и медленными, посмотрите на разбиение таблиц .

1 голос
/ 26 ноября 2009

Это называется мультитенантным приложением, и многие люди запускают его; см

тег мультитенанта

По вопросам других людей

1 голос
/ 26 ноября 2009

Я бы рекомендовал использовать отдельные базы данных для каждого пользователя. Это упрощает кодирование приложения и обслуживание MySQL (миграция одной учетной записи, удаление учетной записи и т. Д.)

Единственное исключение из этого правила может быть, если вам нужен доступ к данным между учетными записями или обмен данными.

1 голос
/ 26 ноября 2009

Это зависит от того, что вы собираетесь делать с данными. Если клиенты не делятся данными, сегментирование по клиентам может быть лучше; Кроме того, вы можете получить лучшую производительность.

С другой стороны, наличие множества таблиц с одинаковой структурой может стать кошмаром, если вы хотите изменить структуру.

...