Saas модель изоляции данных

Question

У меня есть приложение, написанное на php с использованием фреймворка Symfony. Вместо отдельной установки для клиента на размещенном сервере я бы хотел перейти к модели SaaS с одной установкой для всех клиентов, где возможно выполнение кода Google или другой облачной службы. Я не привязан к PHP, хотя я хотел бы получить пользу от хорошего фреймворка.

Итак, задача: если все клиенты используют одно и то же приложение, у нас есть способ изолировать данные каждого клиента. Клиенты, например, имеют доступ администратора и могут управлять своими пользователями и привилегиями. На простом уровне можно просто указать идентификатор организации в каждой таблице и добавить его ко всем операциям с базой данных. Однако большинство фреймворков приложений используют и ORM, и я не смог найти тот, который бы легко / казалось бы облегчил это на уровне, который минимально влияет на код приложения.

Кто-нибудь смотрел на это, есть ли хорошие подходы к этой проблеме?

Answer 1

Как говорит Итай, мультитенантная система является распространенным требованием.Некоторое время назад я провел некоторое исследование по этой проблеме и наткнулся на довольно хорошую презентацию о различных способах решения этой проблемы, а также о плюсах и минусах каждого: http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html

Эта конкретная презентация предназначенааудитория Rails, но принципы такие же, как и у любого языка.

Answer 2

Эта статья MSDN дает вам очень хороший обзор архитектуры данных в мультитенантности: http://msdn.microsoft.com/en-us/library/aa479086.aspx

Answer 3

Подход, который вы описали, является распространенным, и PHP (одна из сильных сторон) позволит вам сравнительно легко войти в код ORM и изменить его в соответствии с вашими потребностями.

Второй подход заключается в создании отдельной БД для каждой организации и совместной БД для общих ресурсов.
Немного проблем дизайна (но только немного).

если вы действительно большой, то вам даже нужно будет рассмотреть отдельный сервер БД для каждой организации (я бы сказал, что это серьезный перебор в 99,9999% случаев).