Einzelne V / s, mehrere Datenbanken

Ich habe diese Web-App (php & mysql) erstellt, die Informationen für verschiedene Organisationen speichert (derzeit ca. 20 Kunden).

Im aktuellen Szenario werden clientbezogene Informationen in einzelnen Datenbanken gespeichert, sodass 20 Clientdatenbanken und 1 Masterdatenbank vorhanden sind.

Einer der Hauptvorteile hierbei ist, dass die Nummerierung der Client-Artefakte (Berichte, Audits) usw. sequenziert wird, wenn jede Client-Datenbank isoliert ist. Unseren Kunden ein Gefühl der Sicherheit geben.

Jede Datenbank verfügt über ungefähr 15 Tabellen, und die meisten Zeilen in einer Tabelle sind ungefähr 2000. Es wird erwartet, dass maximal 5000 Datensätze vorhanden sind.

Das Verwalten einer einzelnen Änderung auf Datenbankebene bedeutet das Ändern von 20 Datenbanken. In dem seltenen Fall, dass ich eine solche Änderung vornehmen muss, verwende ich ein Skript, das dies in einem einzelnen Funktionsaufruf ausführt.

Wir haben ein Shared-Hosting-Arrangement und unser ISP liefert uns eine eingeschränkte Nummer. von Datenbanken; und das hat mich veranlasst, über die Zentralisierung der Datenbank nachzudenken; Damit können ALLE Kundendaten in der Stammdatenbank gespeichert werden.

Einige wichtige Punkte, die auftauchen, sind natürlich:

ein. Beibehalten der Artefaktsequenz (dies kann durch Erstellen eines zusätzlichen Referenzschlüssels behoben werden) b. Geschwindigkeit und Leistung (in diesem Fall kann ich Indizes erstellen, um die Dinge zu beschleunigen) c. Sicherheit: Dies wird als jede Abfrage verwaltet, die Client-Informationen abruft. verfolgen auch ihre client_id

In Zukunft müssen wir vielleicht überlegen, ob wir die Datensätze einer Organisation mit denen einer anderen vergleichen sollen, aber ich glaube, dass dies auch mit einer zentralen Datenbank erreicht werden kann. Ich bin (aus Gründen der Leistung und Wartbarkeit) eher geneigt, auf eine zentralisierte Datenbank umzusteigen.

Halten Sie es für sinnvoller, auf eine zentralisierte Datenbank umzusteigen, als so zu bleiben, wie wir es sind (bei einzelnen Datenbanken)?

Danke für deinen Rat.

Es gibt Risiken und Chancen für beide Systeme. Ich arbeitete für eine Finanzfirma, die ungefähr 40 Kunden (Nationalbanken) in einer Datenbank betreute. Wir kauften dann eine andere Firma, die ähnliche Software verkaufte und die mit 1 Datenbank pro Kunde gegangen war. Schließlich ging das Unternehmen in Konkurs und wir mussten alle Benutzerdaten exportieren. Hier sind die Leute, mit denen ich gearbeitet habe und die ich gefunden habe:

Pro's von Single DB:

1. Software-Updates und Fehlerkorrekturen sind einfacher.
2. Einfache Verwaltung und Protokollierung aller Kundendaten.
3. Das Aktualisieren von Daten wird einfacher.
4. Einfaches Erstellen modularer Funktionen, die ein Client benötigt. Deaktivieren Sie diese, wenn Sie dies für die anderen Clients wünschen, und aktivieren Sie sie dann, wenn sie dies in Zukunft wünschen.

Con's von Single DB:

1. Datenintegrität - Wir hatten 2 oder 3 Fälle, in denen Benutzer einer Bank die Daten einer anderen Bank sahen. Das war ein Albtraum. Vor allem, weil die Benutzer der Website nicht nur die Bankangestellten, sondern auch die tatsächlichen Kunden der Bank waren! Dies ist mit Abstand das größte Problem mit 1 Datenbank
2. Exportieren von Kundendaten - Wenn wir das mussten, war es normalerweise keine große Sache. Am Ende haben Sie eine Tabelle, in der alle Clients enthalten sind, und Sie tippen diese Tabelle ab, um Ihre clientspezifischen Daten abzurufen.

Vorteile mehrerer DBs:

1. Es gibt keine Bedenken hinsichtlich der Kontamination oder Verletzung von mandantenübergreifenden Daten
2. Das Exportieren von Kundendaten ist kinderleicht.

Nachteile mehrerer DBs:

1. Updates und Fehlerbehebungen - Dies war der wahre Albtraum. Wenn Sie 20 Clients in 20 verschiedenen Datenbanken haben, stoßen Sie schnell auf den Fall, dass 1 Client einen Fehler behoben haben möchte und ein anderer denkt, dass der Fehler eine Funktion ist oder das Update nicht riskieren möchte. Außerdem gibt es Fälle, in denen 1 Client eine bahnbrechende Verbesserung wünscht, die anderen Clients jedoch nicht. In diesem Fall beginnen Ihre Datenbanken zu divergieren. Plötzlich müssen Sie die Clients 1-15 mit 1 Skript 16-19 mit einem anderen und 20 mit einem dritten aktualisieren. Wir sahen, dass dies zu einem solchen Problem wurde, dass eine Fehlerbehebung für das von uns gekaufte Unternehmen 15- bis 20-mal länger dauern würde als für uns, da alle Tests für jeden Kunden durchgeführt und der spezielle Code jedes Kunden behandelt werden musste. Tatsächlich brauchten sie für jeden neuen Kunden einen neuen Betreuer.
2. DB-Verwaltung - Wenn Sie zu einer großen Anzahl von Clients gelangen, wird die Verwaltung aller Datenbanken zu einem echten Problem. Sie werden ohne Zweifel mehr DBA-Zeit benötigen, um sie zu verwalten.

Am Ende ist meine Empfehlung, beides gesehen und getan zu haben, "Disziplin" zu haben! Ich denke, die Multi-DB-Auswahl ist etwas besser, weil sie Sie schützt, aber Sie können nicht zulassen, dass Ihre Kunden eine Auswahl treffen, die Sie dazu veranlasst, nur ihnen Funktionen hinzuzufügen, oder Sie werden sich auf einen Pfad des Scheiterns begeben.

Ich hätte eine separate Datenbank für separate Kunden. Ein Kunde kann dies aus Sicherheitsgründen verlangen - dh nur seine Site hat Zugriff auf seine Daten. Dies bedeutet auch, dass die Verwaltung eines Kunden, der seine Daten verschieben möchte, erheblich vereinfacht wird.

Dies bedeutet auch, dass bei Problemen mit der Datenbank eines Clients nicht alle anderen Clients betroffen sind.

Wenn Sie Daten zwischen Clients vergleichen möchten, sollten Sie dies separat tun.

Wenn Ihnen die Datenbanken ausgehen, über die Sie verfügen können, sollten Sie möglicherweise überlegen, Ihren Host-Provider zu ändern.

Der einzige Grund, warum ich nicht für jeden Kunden eine eigene Datenbank hätte, ist, wenn Sie 100 oder 1000 Kunden / Datenbanken haben wollen. Dies kann sehr schwierig zu handhaben sein, z. B. Änderungen an der Datenbank oder eine datenbankübergreifende Aktion. Aktionen, die in einer großen Anzahl von Datenbanken ausgeführt werden, können auch langsam sein, da Sie so viele Tabellen öffnen (und daher schließen) müssen.

Abgesehen von diesem Fall halte ich mehrere Datenbanken für besser.

Ein Vorteil, der nicht wichtig, aber nützlich sein kann, ist, dass jeder Client seine eigenen sequenziellen IDs erhält (anstatt möglicherweise einen Haufen zu überspringen, weil ein anderer Client Datensätze hinzugefügt hat).

Durch mehrere Datenbanken können die Untertabellen (z. B. der Telefontyp) problemlos pro Client angepasst werden, ohne dass auch in diesen Tabellen eine übergeordnete Datensatz-ID erforderlich ist.

Zuerst die Artefaktsequenzierung. Ich gehe davon aus, dass Sie dafür ganzzahlige Primärschlüssel verwenden. Wirklich, Sie sollten eine separate Spalte "Artefaktnummer" haben. PK's sollten PK's sein und sonst nichts. Die Leute reden über "natürliche Schlüssel" und dergleichen, und ich zucke zusammen. Wenn Sie sich darauf verlassen, dass die PK mehr als eine Kennung ist, wird sie Sie immer wieder beißen. Wenn Sie die Sequenz von etwas wissen möchten, speichern Sie ein Datum oder eine Sequenznummer.

Ich denke, in Ihrem Fall würde das Konfigurationsmanagement Sie zu einer einzigen Datenbank führen. Sehen Sie sich an, was Sie Zeit kostet, um Datenbanken zu warten und zu aktualisieren. Welche Kosten sind mit jeder Version der Software verbunden? Denken Sie auch an die Kosten, wenn Sie einen neuen Kunden gewinnen und eine Datenbank erstellen und die App dafür konfigurieren müssen. Alles kann automatisiert werden, die Frage ist, lohnt es sich, wenn Sie 100 Datenbanken haben?

Auf der anderen Seite ist es einfacher, eine einzelne Datenbank zu skalieren (Partitionierung, Hardware, Sharding usw.), als dies für 100 Datenbanken zu tun.

Ich denke, die anderen Plakate haben einige hervorragende Punkte hervorgebracht, deshalb gehe ich nicht darüber hinweg.

So fügen Sie die bisher aufgelisteten Vor- / Nachteile hinzu:

Vorteile mehrerer Datenbanken:

1. Sperrprobleme werden vermieden. Wir haben Datenbanken, in denen die Clients DDL-Änderungen an einigen Tabellen auslösen können. Bei den größeren Tabellen (> 2 m Datensätze) wird die Tabelle für einen beträchtlichen Zeitraum gesperrt. Die einzigen Menschen, die im Nachteil sind, sind ihre eigenen Benutzer. Das ist also irgendwie akzeptabel.

2. Flexibilität - Einige Kunden haben spezielle Wünsche bezüglich der Daten, die sie speichern möchten. Multi-Database ermöglichte uns die Flexibilität, ihre Datenbank spezifisch zu ändern, ohne das Datenmodell für die anderen Clients überladen zu müssen.

Nachteile:

1. Hauptbetrug: An anderen Tischen mitzumachen ist viel umständlicher. Wir haben eine Hauptdatenbank, die die meisten Metadaten enthält. Die clientspezifischen Datenbankbenutzer haben keinen Zugriff auf diese Datenbank. Daher werden alle Verknüpfungen zwischen Tabellen in dieser und der clientspezifischen Datenbank in der Anwendung und nicht in der Datenbank verarbeitet. Sie können dieses Problem beheben, indem Sie den clientspezifischen Benutzern Zugriff auf die Hauptdatenbank gewähren. In diesem Fall kann die App jedoch erneut Daten verlieren.

Viel Glück bei der Auswahl!

Ich weiß, dass Sie bereits eine Antwort ausgewählt haben, aber es sieht so aus, als gäbe es eine andere Lösung, die nicht vorgeschlagen wurde:

Verschieben Sie alles in eine Datenbank, aber erstellen Sie Tabellen für jeden Kunden mit einem Präfix wie folgt:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

Es ist das Beste aus beiden Welten.

• Es ist sehr einfach, von Ihrem aktuellen Setup auf das neue Setup zu migrieren.
• Sie können pro Mandant einen Benutzer anlegen und dessen Rechte auf die Tabellen seines Unternehmens und nichts anderes beschränken
• Sie können einen Superuser erstellen und bei Bedarf einfach Daten aggregieren.
• Verwenden Sie nur eine Datenbank