Quelles sont les meilleures pratiques en matière de création d'applications prenant en charge plusieurs locataires, tels que Software as a Service?Quelles sont les meilleures pratiques pour construire des applications de multi-location?
Les liens vers des livres blancs qui développent ce sujet sont grandement appréciés.
Vous trouverez peut-être des conseils précieux dans une série de billets de blog par Oren Eini.
Ceci est l'un des derniers messages de la série, avec des liens vers les messages précédents: http://ayende.com/Blog/archive/2008/08/16/Multi-Tenancy--Approaches-and-Applicability.aspx
Pour la base de données:
A. Mettez tout sur la même base de données, mettez une colonne de tenant_id sur vos tables
Avantages: Facile à faire
Inconvénients: Très sujettes à des bogues: il est facile de fuir les données d'un locataire à un autre.
B. Mettez tout sur la même base de données, mais chaque locataire a mis sous son propre nom (postgresql les appelle schémas)
Avantages: Fournit une meilleure protection des données de fuite que l'option A
Moins: Non supporté par toutes les bases de données. AFAIK PostgreSQL et Oracle le supportent.
C. Configuration d'une base de données par locataire
Plus: Absolument aucune chance de données fuite d'un locataire à un autre
Inconvénients: La création de nouveaux locataires est plus complexe. Les connexions aux bases de données sont chères.
J'ai seulement appris les idées ci-dessus de Guy Naor. Voici un lien vers sa présentation: http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html
Dans # B, tous les schémas de soutien des bases de données, mais avec une terminologie différente. En MySQL, le schéma et la base de données sont synonymes. MSSQL a également le support des schémas maintenant. Notre application multitenancy en production fonctionne avec environ 4000 bases de données/schémas sur MySQL. –