Лучшая практика использования поддоменов в стиле Rails Basecamp - PullRequest
Новая
       0

Лучшая практика использования поддоменов в стиле Rails Basecamp

7 голосов
/ 17 февраля 2011

Моя цель - создать отдельные учетные записи для каждого субдомена.Ни при каких обстоятельствах я не хочу перекрестного опыления между поддоменами.

Я просмотрел Робби Рассла и мыслей DHH (хотя оба являются pre-Rails3).

Работа с контроллером довольно проста, мои вопросы касаются разделения данных модели.Каков наилучший способ запретить пользователю user1 просматривать данные user2?

Некоторые идеи могут включать:

  1. Добавление внешнего ключа subdomain_id для каждой модели - Преимущество, простое отношение «один ко многим» может использоваться для охвата каждой модели субдоменом.- Недостаток , это довольно тесная связь между данными и более широкой логикой приложения, что кажется неуместным.

  2. One-to-many :through для каждой модели, связывающей ее с поддоменом- Преимущество , нет необходимости добавлять столбец внешнего ключа subdomain_id к существующим таблицам, связывая их с их поддоменом.- Недостаток , мое интуитивное ощущение, что это слишком много.Множественные запросы на объединение могут стать сложными, и могут возникнуть ошибки перекрестного опыления.

  3. Отдельные приложения или базы данных для каждого субдомена - Преимущество , данные полностью сегрегированы.- Недостаток , необходимо будет управлять / обновлять / защищать / размещать / т.д. большое количество отдельных приложений / баз данных

  4. Ваша идея?

Ответы [ 2 ]

7 голосов
/ 18 февраля 2011

Вариант 5. Решение схемы Гая Наора - Преимущество , Это просто взорвало мой разум. Преимущественно прозрачный для рельсов, полное разделение данных, только одна база данных, отлично работает для приложений, которые изначально не были разработаны как мультитенантные. удивительно. - Недостаток , необходимо использовать Postgres или какую-либо другую базу данных, которая поддерживает схемы (в любом случае, я уже использую PG), вам придется перебирать существующие схемы при миграции.

Сейчас это кажется лучшим способом. Есть ли серьезные недостатки?

1 голос
/ 17 февраля 2011

Если вы уверены, что отношение объекта к поддомену всегда будет взаимно-однозначным, я бы выбрал вариант 1. Если в будущем объекты могут быть связаны с несколькими поддоменами, вы должны использовать вариант 2. ЭтоЭто приводит к дополнительным накладным расходам, но с ним легко справиться, если использовать что-то вроде cancan.

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

...