Welche Best Practices werden beim Erstellen von Anwendungen verwendet, die mehrere Mandanten unterstützen, z. B. Software as a Service?Was sind die besten Praktiken beim Erstellen von Mandantenfähigkeitsanwendungen?
Links zu White Papers, die zu diesem Thema erweitert werden, werden sehr geschätzt.
Sie könnten einige wertvolle Ratschläge in einer Reihe von Blog-Posts von Oren Eini finden.
Dies ist einer der letzten Beiträge in der Reihe ist, mit Links zu früheren Beiträgen: http://ayende.com/Blog/archive/2008/08/16/Multi-Tenancy--Approaches-and-Applicability.aspx
Für die Datenbank:
A. alles auf der gleichen Datenbank Stoßen, eine tenant_id Spalte auf Ihre Tabellen zu setzen
Vorteile: Einfache
Nachteile zu tun: Sehr anfällig für Fehler: Es ist leicht, Daten von einem Mandanten zu einem anderen zu verlieren.
B. alles auf der gleichen Datenbank Stoßen, sondern setzen für jeden Gast in seinen eigenen Namensraum (postgresql nennt sie Schemata)
Vorteile: Bietet einen besseren Datenschutz als Option Leck
Nachteile: Nicht unterstützt von allen Datenbanken. AFAIK PostgreSQL und Oracle unterstützt es.
C. Einrichtung eine Datenbank pro Mieter
Vorteile: Absolut keine Chance von Daten von einem Mieter zu einer anderen
Cons undicht: neue Mieter Einrichtung ist komplizierter. Datenbankverbindungen sind teuer.
Die obigen Ideen habe ich nur von Guy Naor gelernt. Hier ist ein Link zu seiner Präsentation: http://aac2009.confreaks.com/06-feb-2009-14-30-writing-multi-tenant-applications-in-rails-guy-naor.html
In #B, alle Support-Datenbanken Schemata, jedoch mit unterschiedlicher Terminologie. In MySQL sind Schema und Datenbank synonym. MSSQL unterstützt jetzt auch Schemas. Unsere Multitenancy-App in Produktion läuft mit ~ 4000 (ab sofort) Datenbanken/Schemas auf MySQL. –