Wir genau vor ein paar Monaten dieses Problem hatte in einem Produkt, das häufig von Organisationen verwendet wird, die wiederum mehrere Kunden bedienen. Sie kamen zu uns und baten uns, unser SaaS-System so zu modifizieren, dass sie für jeden ihrer Kunden komplette, diskrete Websites erstellen konnten (wir erstellen ein Online-Tool für die Erstellung von domänenspezifischen Websites).
Eine kurze Zusammenfassung: Es scheint naheliegend, alle auf eine einzige Datenbank zu setzen, aber wenn Sie tiefer suchen, werden Sie feststellen, dass es nicht immer geschnitten und trocken ist. Es gibt ein paar Herausforderungen, die Sie im Auge behalten sollten, während Sie fortfahren. Ein paar Punkte:
Erstens ist es nicht genug, nur "Company_id" zu einigen Tabellen hinzuzufügen. In der Tat, trotz der Kommentare von Sai, dass es lächerlich ist, eine Datenbank/App für jedes Unternehmen zu haben, gibt es absolut Fälle, wo dies aufgrund der zugrunde liegenden Komplexität des Hosting von SaaS-Systemen für mehrere, diskrete Clients sinnvoll ist. Wenn Sie nur ein paar verschiedene Unternehmen (z. B. Erstellen von Rechnungen für sie) servieren, dann Sais Kommentar ist ziemlich wahr. Wenn Sie jedoch eine Softwareanwendung für mehrere Organisationen bereitstellen, ist die Komplexität ein wenig höher und diskrete Datenbanken sind möglicherweise in Ordnung.
Zweitens, bereiten Sie sich auf einen wesentlich komplexeren Benutzerabfrage- und Berichtsaufwand in einer Multi-Client-Datenbank vor. Zum Beispiel mussten wir beim Aufbau unserer Benutzerabfrage-Funktionen absolut sicher sein, dass es zwischen den Organisationen kein "Durchscheinen" geben würde, da HIPAA-geschützte Daten involviert waren. Dies bedeutete, dass die Abfrage- und Berichtsfunktionen ein Engineering-Niveau erforderten, das weit über das vorhergehende hinausging.In unserem Fall waren unsere Abfragemöglichkeiten sehr flexibel und ermöglichten es den Benutzern im Wesentlichen, Abfragen im laufenden Betrieb zu erstellen (mit einigen ziemlich strengen Einschränkungen, offensichtlich - wir akzeptierten nicht SQL!). Daher mussten wir sicherstellen, dass jede Abfrage automatisch so angepasst wurde, dass sie die Einschränkung "Company_ID" verwendete, unabhängig von der Herkunft der Daten oder den Berechtigungen des Mitarbeiters, der die Abfrage einreichte. Die Falte? Unser "Super-User" -Analysekonto musste in der Lage sein, die Abfragen ohne eine solche Einschränkung auszuführen ...
Drittens haben Sie wahrscheinlich noch nicht vorhergesehen, wie viele Dinge getrennt werden müssen. Zum Beispiel hatte ich ein recht ausgeklügeltes "Settings" -Objekt in die Site eingebaut, das beim Start Einstellungen aus der Datenbank übernommen und im "Application" -Objekt gepflegt hat (das ist eine .NET-App). Dies alles musste implementiert werden, um mehrere Organisationen zu verwalten.
In einem anderen Beispiel mussten Felder, die früher für uns eindeutig waren (z. B. Logins), nun als Teil einer Company_ID, LoginID-Schlüssel, ausgeführt werden. Wenn Sie von Grund auf neu bauen, ist das keine so große Idee, aber wir haben es nachgerüstet.
Wie auch immer, als ich durch den Build ging, war ich überrascht herauszufinden, wie viel Arbeit erforderlich war, um dies richtig zu machen.
Viertens, ich baue Software immer mit einem "Meta-Programmierung" -Ansatz. Das heißt, ich baue selten eine Single-Purpose-Seite, sondern baue oft ein hochgradig anpassbares Framework, um die Anpassung des Endbenutzers und die Wiederverwendung von internem Code zu erleichtern. Während ich antizipierte, dass dies beim Übergang zu Datenbanken mit mehreren Organisationen helfen würde, war dies oft nicht der Fall! Da eine solche Codierung von Anfang an oft ziemlich komplex ist, war es oft schwieriger, die Organisation zu verbreiten, als wenn ich einfach eine Vanilla-Webseite hätte.
Schließlich, wenn es keine weinende Notwendigkeit gibt, Daten zu teilen (z. B. Analyse der allgemeinen Nutzungsmuster), dann möchten Sie vielleicht mit diskreten Datenbanken einfach zur Vereinfachung der Skalierung bleiben. Während Sie neue Multi-Org-Datenbanken hinzufügen (ein zweites eigenständiges System), wurden bei unserer Skalierung häufig vorhandene Clients berücksichtigt, die plötzlich einen starken Anstieg aufwiesen. Sie aus einer vorhandenen Datenbank auf einen neuen Server zu ziehen, ist etwas schwieriger, als nur auf einen neuen Server mit einer vorhandenen Datenbank umzusteigen.
Mit all diesen Vorbehalten könnte man meinen, ich würde Sie davon abraten, ein System zu entwickeln, das mehrere Organisationen in einer einzigen Datenbank verwalten kann. Dies ist jedoch nicht der Fall: Es gibt einige echte Gewinne, die einen Multi-Org-Ansatz verfolgen! Nutzungsanalyse, organisationsübergreifendes Reporting, Anwendungsbereitstellung usw. werden alle erheblich verbessert. Ich möchte Ihnen nur den Nutzen unserer Erfahrung bieten, in der Hoffnung, dass Sie damit einige der Schwierigkeiten, die Sie erwarten, vorhersehen können.
Nein, ich betrachte die DB nicht direkt. Meine Sorge war nur die Leistung auf längere Sicht. Und ja, es sieht jetzt albern aus, DBs zu replizieren - irgendwelche Änderungen im Schema, Backups wären entsetzlich. –
Dies hängt vollständig davon ab, wie viele Daten pro Unternehmen wir sprechen.In einem allgemeinen Fall funktioniert company_id möglicherweise gut, obwohl es sich bei Salesforce beispielsweise nicht um eine Master/Slave-Architektur handelt, die Sie halten kann, und Sie müssen trotzdem horizontal skalieren (allerdings nicht im Verhältnis 1 DB pro Unternehmen)). Wenn Sie Facebook sind, erstellen Sie eine neue MySQL-Instanz pro Universität und damit können Sie von Anfang an skalieren, obwohl Cross-db-Query-Kopfschmerzen eingeführt werden. – SquareCog
Eigentlich bin ich mir über Salesforce nicht sicher. Wenn man bedenkt, wie langsam es ist, könnte es auf einer einzigen riesigen Oracle RAC-Instanz laufen und versuchen, alle Daten zu verbrennen, wenn Sie Ihre Berichte erstellen :-). – SquareCog