Sollte ich flache Tabellen oder eine normalisierte Datenbank verwenden?

Question

Ich habe eine Webanwendung, an der ich gerade arbeite, die eine MySQL-Datenbank für das Backend verwendet, und ich muss wissen, was für meine Situation besser ist, bevor ich weitermache.

Einfach gesagt, in dieser Anwendung werden Benutzer in der Lage sein, ihre eigenen Formulare mit beliebigen Zahlenfeldern zu konstruieren (sie entscheiden), und jetzt habe ich alles in ein paar Tabellen durch Fremdschlüssel verknüpft. Ein Freund von mir schlägt vor, die Dinge so "einfach/schnell" zu halten, dass ich das Formular jedes Benutzers in eine flache Tabelle umwandeln soll, so dass die Abfrage von Daten von ihnen schnell bleibt (im Falle eines großen Wachstums).

Soll ich die Datenbank normalisieren mit allem in relationalen Tabellen mit Fremdschlüsseln (Indizes, etc.) gepoolten oder sollte ich flache Tabellen für jedes neue Formular erstellen, das ein Benutzer erstellt?

Offensichtlich sind einige Vorteile der Erstellung von flachen Tabellen Datentrennung (Sicherheit) und Abfragegeschwindigkeiten würden reduziert werden. Aber ernsthaft, wie viel Gewinn würde ich daraus ziehen? Ich will wirklich nicht 10000 Tische haben und die ganze Zeit fallen lassen, verändern und hinzufügen, aber wenn es besser wird als ich es tun werde ... brauche ich nur etwas Input.

Vielen Dank

Answer 1

Faustregel. Es ist einfacher, von Normalisierung zu Denormalisierung zu wechseln als umgekehrt.

Beginnen Sie mit einem vernünftigen Niveau der Datenbanknormalisierung (mit vernünftigen ich meine lesbar, wartbar und effizient, aber nicht vorzeitig optimiert), dann, wenn Sie Leistungsprobleme wie Sie wachsen, haben Sie die Möglichkeit, in Möglichkeiten, in denen Denormalisierung kann die Leistung erhöhen.

Answer 2

Das Ändern des Schemas zur Laufzeit ist selten eine gute Idee. Was Sie berücksichtigen möchten, ist das Modell EAV (Entity-Attribut-Value).

Wikipedia hat some very good info über die Vor- und Nachteile sowie Implementierungsdetails. EAV ist zu vermeiden, wenn möglich, aber für Situationen wie Ihres mit einer unbekannten Anzahl von Spalten für jedes Formular, EAV ist in Betracht zu ziehen.

Answer 3

Halten Sie Ihre Daten normalisiert. Das System sollte schnell bleiben, vorausgesetzt, Sie haben eine korrekte Indexierung.

Wenn Sie wirklich schnell gehen wollen, dann wechseln Sie das Schema zu einer der Schlüsselwertdatenbanken wie bigDB/couchDB usw. Das ist total denormalisiert und sehr, sehr schnell.

Answer 4

... in dieser Anmeldung Benutzer in der Lage sein werden, ihre eigenen Formulare mit einer beliebigen Anzahl Felder ...

Huch zu bauen! Dann wie könnten Sie möglicherweise irgendeine Art von Normalisierung tun, wenn die Benutzer, in essense, die Datenbank Entscheidungen für Sie treffen.

Ich denke, Sie müssen es entweder Schritt für Schritt verwalten oder lassen Sie Ihre Freak-Flagge fliegen und einfach kaufen Hardware, um mit der Prügel zu halten, die Sie bekommen werden, wenn die Benutzer wirklich anfangen, sich darauf einzulassen ... Sehen Sie sich an, was passiert, wenn Benutzer beginnen, neue Formulare und Ansichten in SharePoint zu erstellen ... CRIKY !! Sprechen Sie über Umfang schleichen !!

Answer 5

Die Art, wie ich damit umgehen würde, ist eine normalisierte, erweiterbare „Property“ Tabelle zu verwenden, wie unten:

Table: FormProperty 
id: pk 
form_id: fk(Form) 
key: varchar(128) 
value: varchar(2048) 

oben The ist nur ein Beispiel, aber ich habe dieses Muster in vielen Fällen verwendet und es tendiert dazu, ziemlich gut zu funktionieren. Das einzige echte "Gotcha" ist, dass Sie den Wert als String/Varchar serialisieren müssen und ihn dann zu dem Deserialisieren müssen, was er auch sein muss. Es gibt also eine kleine zusätzliche Verantwortung für den Client.

Answer 6

Halten Sie Ihre Daten normalisiert. Wenn Sie richtig indizieren, werden Sie für eine sehr lange Zeit nicht auf Leistungsprobleme stoßen.

In Bezug auf Sicherheit: Der flache Ansatz erfordert, dass Sie viele create/drop table, alter table etc Anweisungen schreiben, dh viel mehr Code und eine Menge weiterer Fehlerpunkte.

Der einzige Grund, flache Dateien zu haben, wäre, wenn sich Ihre Benutzer direkt mit der Datenbank verbinden könnten (Sie könnten immer noch für die Sicherheit auf Zeilenebene gehen). Aber in diesem Fall sind die Neuimplementierung Sie wirklich eine Variante von phpMyAdmin

Answer 7

Normalized == schnellen Suche, einfacher Indizes zu halten, langsame Insert-Transaktionen (auf mehreren Zeilen)

Denormalisierte == schnelle Einsätze, ususally diese verwendet wird, wenn es viele Einfügungen gibt (Data Warehouses, die chronologische Daten sammeln und aufzeichnen)