PHP-Webanwendung: Mysql Datenbank Design Best Practices Frage

Question

Ich bin derzeit in einer Debatte mit einem Kollegen über die Best Practices in Bezug auf das Datenbankdesign einer PHP-Webanwendung, die wir erstellen. Die Anwendung ist für Unternehmen konzipiert, und jedes Unternehmen, das sich anmeldet, wird mehrere Benutzer haben, die die Anwendung verwenden.

Meine Entwurfsmethodik ist, eine neue Datenbank für jedes Unternehmen zu erstellen, das sich anmeldet. So ist alles sandboxed, modular und klein. Die Philosophie meiner Mitarbeiter besteht darin, alle in eine Datenbank zu stellen. Sein Argument ist, dass wir, wenn wir mehr als 1000 Unternehmen haben, mit über 1000 Datenbanken fertig werden. Ganz zu schweigen von der Unordnung, die Business Intelligence macht.

Nehmen wir als Beispiel an, dass die Anwendung ein Auftragserfassungssystem ist. Mit separaten Datenbanken kann die Tabellengröße auch dann überschaubar bleiben, wenn jede Firma mehr als 100 Aufträge pro Tag erledigt. In einer Single-Bucket-Anwendung können Tabellen sehr schnell sehr groß werden.

Gibt es eine Best Practice dafür? Ich habe versucht, im Web zu jagen, hatte aber nicht viel Erfolg. Links, Whitepaper und Präsentationen sind willkommen.

Vielen Dank im Voraus,

The1Rob

Answer 1

Ich sprach mit dem Datenbankarchitekten von Wordpress.com, dem Hosting-Service für WordPress. Er sagte, dass sie mit einer Datenbank anfingen und alle Kunden zusammen hosten. Der Inhalt einer einzelnen Blog-Site ist wirklich nicht so viel. Es liegt nahe, dass eine einzige Datenbank überschaubarer ist.

tat diese Arbeit für sie gut, bis sie Hunderte und Tausende von Kunden bekommen, erkannten sie, dass sie zu Skala aus erforderlich, mehrere physische Server ausgeführt wird und eine Teilmenge ihrer Kunden auf jedem Server-Hosting. Wenn sie einen Server hinzufügen, wäre es einfach, einzelne Kunden auf den neuen Server zu migrieren, aber es ist schwieriger, Daten in einer einzigen Datenbank zu trennen, die zu einem Blog eines einzelnen Kunden gehört.

Da Kunden kommen und gehen, und einige Blogs von Kunden große Mengen an Aktivität haben, während andere alt werden, wird das Rebalancing über mehrere Server zu einem noch komplexeren Wartungsauftrag. Die Überwachung der Größe und Aktivität pro einzelner Datenbank ist ebenfalls einfacher.

Ebenso eine Datenbank Sicherung oder Wiederherstellung einer einzigen Datenbank zu tun Terrabyte an Daten, im Vergleich zu einzelnen Datenbank-Backups und Wiederherstellungen von wenigen Megabyte je enthält, ist ein wichtiger Faktor. Bedenken Sie: Ein Kunde ruft an und sagt, dass seine Daten aufgrund einer schlechten Dateneingabe SNAFU erhalten haben. Könnten Sie bitte die Daten aus dem gestrigen Backup wiederherstellen? Wie würden Sie eine Kundendaten wiederherstellen, wenn alle Ihre Kunden eine einzige Datenbank teilen?

Schließlich entschieden sie, dass die Aufteilung in eine separate Datenbank pro Kunde, obwohl komplex zu verwalten, bot ihnen größere Flexibilität und sie neu gestaltet ihren Hosting-Service für dieses Modell.

So, während von einer Datenmodellierung Perspektive es wie das Richtige scheint alles in einer einzigen Datenbank zu tun zu halten, einige Datenbank-Administration Aufgaben werden einfacher, da Sie einen bestimmten Grenzwert von Datenvolumen übergeben.

Answer 2

Ich persönlich habe nicht mit dieser Situation behandelt, aber ich würde denken, dass, wenn Sie Business Intelligence tun wollen, sollten Sie die Daten in eine Offline-Datenbank Aggregat, das Sie können dann jede gewünschte Analyse ausführen.

Wenn Sie sie in separaten Datenbanken aufbewahren, wird die Partitionierung zwischen Servern vereinfacht (was Sie wahrscheinlich tun müssen, wenn Sie mehr als 1000 Kunden haben), ohne auf unordentliche Replikationstechnologien zurückgreifen zu müssen.

Answer 3

Ich hatte eine ähnliche Frage vor einer Weile und kam zu dem Schluss, dass eine einzige Datenbank drastisch überschaubarer ist. Im Moment haben wir mehrere Datenbanken (etwa 10) und es ist schon ein Problem, es zu verwalten, besonders wenn wir den Code aktualisieren. Wir müssen jede einzelne Datenbank migrieren.

Der Vorteil ist, dass die Daten sauber getrennt sind. Aufgrund der Sensibilität unserer Daten ist das eine gute Sache, aber es macht es ein bisschen schwieriger mitzuhalten.

Answer 4

Die separate Datenbank-Methodik hat einen sehr großen Fortschritt gegenüber dem anderen:
+ Sie könnten es in kleinere Gruppen aufgeteilt, diese Architektur skaliert viel besser.
+ Sie können auf einfache Weise eigenständige Server erstellen.

Answer 5

Ich würde nie eine neue Datenbank für jede Firma erstellen. Wenn Sie ein modulares Design wünschen, können Sie dies mithilfe von Tabellen und ordnungsgemäß verbundenen primären und sekundären Schlüsseln erstellen. Dies ist, wo ich über database normalization gelernt habe und ich bin sicher, dass es Ihnen hier helfen wird.

Dies ist die Methode, die ich verwenden würde. SQL Article

Answer 6

Das hängt davon ab, wie wahrscheinlich Ihre Schemas geändert werden sollen. Wenn Sie sich jemals ändern müssen, können Sie diese Änderungen sicher in 1000 separaten Datenbanken vornehmen? Wenn ein Skalierbarkeitsproblem in Ihrem Design gefunden wird, wie werden Sie es für 1000 Datenbanken reparieren?

Answer 7

Wir betreiben ein SaaS-Geschäft (Software-as-a-Service) mit einer großen Anzahl von Kunden und haben beschlossen, alle Kunden in derselben Datenbank zu halten. Die Verwaltung von 1000 separaten Datenbanken ist ein betrieblicher Albtraum.

Sie müssen Ihr Datenmodell und die Geschäftsobjekte/Berichtsabfragen, die auf sie zugreifen, sehr gewissenhaft erstellen. Ein Ansatz, den Sie in Betracht ziehen sollten, ist, die Firmen-ID in jeder Tabelle zu tragen und sicherzustellen, dass jede WHERE-Klausel die Firmen-ID für den aktuell angemeldeten Benutzer enthält. Wenn Sie eine Datenzugriffsebene verwenden, können Sie diese Bedingung dort erzwingen.

Wenn Sie groß werden, können Sie immer noch vertikal partitionieren, indem Sie Gruppen von Unternehmen auf jedem physischen Server platzieren, z. die ersten 100 Unternehmen auf Server A, die nächsten 100 Unternehmen auf Server B.

Answer 8

Ich müsste Ihrem Kollegen zustimmen. Relationale Datenbanken sind darauf ausgelegt, große Datenmengen zu verarbeiten, und die Zahlen, über die Sie sprechen (mehr als 1000 Unternehmen, mehrere Benutzer pro Unternehmen, mehr als 100 Bestellungen/Tag) liegen innerhalb der erwarteten Grenzen. Separate Datenbanken bedeutet:

• mehrere Datenbankverbindungen in jedem Skript (Speicher und Geschwindigkeit Strafe)
• Wartung ist härter (DB-Systeme im Allgemeinen bieten keine Werkzeuge für die als Gruppe auf Datenbanken handelt) so Schemaänderungen, Backups, und ähnliche Aufgaben wird schwieriger
• härter Abfragen auf Daten von mehreren Unternehmen laufen

Wenn Ihre Website wird riesig, können Sie eventuell benötigen, um Ihre Daten auf mehrere Server zu verteilen. Gehen Sie damit um, wenn es passiert. Um aus Performance-Gründen so zu starten, klingt das nach voreiliger Optimierung.