2010-12-15 20 views
13

Ich arbeite an einer App, die Daten von Smartcards sammelt. Ich möchte die App als Web-Service für mehrere Kundenkonten ausführen können. Die Frage ist, sollte ich für jedes Konto eine separate Datenbank erstellen oder sollte ich eine einzelne Datenbank entwerfen, die alle Daten der Konten enthält? Zuerst dachte ich, dass eine einzige Datenbank die offensichtliche Antwort war, aber es führt dazu, dass überallEinzelne oder separate Datenbanken für separate Kundenkonten?

in dieser App verwendet werden muss ein einzelnes Datenbyte, das zwischen Konten geteilt werden soll.

Zuerst schauen wir uns an, wie eine separate Datenbank für ein Konto aussehen:

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30)); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30)); 

einige Einzigartigkeit Einschränkungen hinzufügen, dass

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName); 
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName); 

Nun, wenn ich alles setzen in einer Datenbank Es bedeutet, dass mehrere Konten dieselben Karteninhaber und SmartCards verwalten können, aber die Konten sollten nicht die jeweils anderen Daten sehen. Aus diesem Grund ist eine SmartCard innerhalb eines Kontos einzigartig, jedoch nicht innerhalb der gesamten Datenbank. So muss jede Einschränkung eine AccountID umfassen,

CREATE TABLE CardHolder ( 
    CardHolderID int, -- primary key 
    CardHolderUniqueName nvarchar(30), 
    AccountID int); 

CREATE TABLE SmartCard (
    SmartCardID int, -- primary key 
    CardHolderID int, 
    CardUniqueName nvarchar(30) 
    AccountID int); 

ALTER TABLE CardHolder 
    ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName); 
ALTER TABLE SmartCard 
    ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName); 

Im eigentlichen DB, wird es viel mehr Tabellen, Spalten und mehrere Indizes (für die Aufnahme in ExpiryDate etc etc) und die AccountID Spalte überall werden muss, enthalten .

Es scheint ein bisschen überladen zu sein, zuerst alle Konten in einer einzigen Datenbank zu setzen und sie dann zu trennen, indem ich eine AccountID-Spalte in jeder Tabelle und fast jeder Einschränkung und Index habe. Ich müsste auch eine Art Sicherheit auf Zeilenebene finden oder erfinden, um Benutzer davon abzuhalten, auf die Daten anderer Konten zuzugreifen. Also, habe ich eine gültige Entschuldigung für die Erstellung einer separaten Datenbank für jedes Konto, oder halten "echte DB-Designer" immer alles in einer einzigen Datenbank?

Antwort

6

Beim Entwerfen einer mandantenfähigen Anwendung müssen mehrere Dinge berücksichtigt werden, einschließlich der Schemas, wie in Ihrer Frage angegeben, aber auch Faktoren wie Lizenzkosten, Skalierbarkeit usw. sollten berücksichtigt werden. This article describes the three most common approaches for designing a multi-tenant application, einschließlich Vor- und Nachteile. Hör zu.

+1

Als Antwort markiert, weil Ihr Link mir die meisten Informationen gab. Ich kann mich immer noch nicht entscheiden, was ich tun soll. Ich werde anfangen, eine DB für mehrere Mieter zu entwerfen, weil es einfacher ist, das in isolierte DBs zu ändern, wenn ich meine Meinung ändere, als es ist, isolierte DBs in ein DB Design umzugestalten. – Batibix

+0

Dieser Link war wirklich großartig. Ich habe viel gelernt. Es sollte Teil eines Buches über den Bau von Saas sein, das ich wahrscheinlich kaufen würde. – racl101

+2

Ich wünschte wirklich du hast das Fleisch dieses Artikels hier gepostet, denn das ist jetzt eine tote Antwort dank link-rot. –

2

IMHO gibt es nur einen Weg. Mehrere Datenbanken

  1. Nicht nur, dass diese vollständig sicheren Daten, die nie
  2. geteilt werden muss Es ermöglicht auch die Schemata unabhängig voneinander zu ändern. Damit meine ich, dass im Laufe der Zeit vielleicht ein Mieter viel größer ist als alle anderen Teanants, und daher muss auf besondere Bedürfnisse eingegangen werden.
  3. Backup, Restore-Operationen und Strategien können leicht für unabhängige Datenbanken
  4. Constraints und Einzigartigkeit ist einfacher und ausgedrückt natürlich
+1

Ich werde nicht in der Lage sein, unabhängige Schemata pro Mieter zu haben, ohne zu laufen in einen Wartungsalarm mit divergierenden App-Versionen etc. – Batibix

+0

Du profitierst immer noch von 1 + 3 + 4 –

+1

Ja, besonders 4, da Einzigartigkeit in einer einzigen DB wirklich komisch wird. Konzeptionell scheint alles in separaten DBs sinnvoller zu sein. Ich bin mir aber nicht sicher über die Wartungs- und Cloud-Hosting-Kosten. – Batibix

5

Wir haben hier unten beiden Routen gegangen formuliert werden. Wir haben eine gemeinsame Datenbank für kleinere Kunden, die keine Anpassung und eine separate Datenbank (und Anwendungscode-Basis für diese Angelegenheit) für Enterprise-Kunden benötigen, die dies tun.

Beide haben ihre Plus- und Minuspunkte. In der gemeinsam genutzten Datenbank wird nur eine ungültige Abfrage benötigt, bei der jemand vergessen hat, die Client-ID zu verwenden, und die Daten anderen Clients zur Verfügung gestellt werden.In fünf Jahren habe ich gesehen, dass dies nur einmal passiert ist, aber es war ein großer Albtraum, der uns einen Klienten kostete. Wenn Sie diesen Weg gehen, stellen Sie sicher, dass Sie ein gutes QA-Team haben, das genau nach diesem sucht, bevor Sie den Code frei geben. Wenn Ihre Datenbank über Schemas verfügt, können Sie Ansichten in Schemas verwenden, um den Datenzugriff auf andere Clientdaten zu verhindern. Wenn der Client nur die Rechte für seine Ansichten hat, kann er niemals die Daten anderer Personen sehen. Dies ist jedoch mehr Arbeit zu richten.

Die einzelnen Datenbanken können jedoch zu einem Albtraum werden, um Wartungsänderungen vorzunehmen. Wenn Sie jedoch Ihre Upgrades verkaufen, ist dies der richtige Weg, da nicht jeder Kunde jedes Upgrade kaufen wird. Stellen Sie nur sicher, dass Sie über einen geeigneten Tracking-Mechanismus verfügen, um zu wissen, auf welcher Version sich jeder Client befindet, und dass Sie die Quellcodeverwaltung verwenden, um alle Datenbankänderungen nach Version zu verfolgen, sodass Sie problemlos upgraden können.

Wenn Sie keine Anpassungen vornehmen möchten, stellen Sie möglicherweise fest, dass separate Datenbanken in diese Richtung führen. Es ist viel einfacher, ihnen zu sagen, wenn sie in einer gemeinsamen Datenbank sind.

Weiter haben wir festgestellt, dass es Anpassungen gibt, die für andere Clients hilfreich sind, aber weil sie in einer separaten Anwendung und Datenbank entwickelt werden, werden sie von einem anderen Team für einen anderen Client neu entwickelt und Sie haben 6 Wege das Gleiche zu tun. Dies wird dann zu einem großen Problem für Leute, die über Clients hinweg arbeiten, wie die Leute, die Kundendaten in die Datenbanken importieren. Persönlich bevorzuge ich den One-Database-Ansatz.

Ein weiterer Punkt, der die Konsolidierung oder Trennung betrifft, betrifft die Berichterstattung über die Daten. Wenn die Berichterstellung immer nur vom Kunden durchgeführt wird, können Sie sie separieren. Wenn Sie jedoch konsolidierte Daten melden möchten (z. B. Ihre eigenen internen Finanzberichte), ist es viel einfacher, wenn Sie über eine konsolidierte Datenbank verfügen. Ich bringe das in die Höhe, weil Leute dazu neigen, die Berichterstattung zu vergessen, bevor das Design festgelegt wurde, und es kann einige ziemlich unangenehme Probleme verursachen, wenn Sie das tun.

+0

Wenn Sie über ein Tool verfügen, das dafür sorgt, dass die Datenbank mithilfe einer Konfigurationsdatei eingerichtet wird, ist dies kein Problem mehr –