Antipattern?

Im allgemeinen Fall ist die zweite Tabelle anti-pattern im Kontext des Datenbankentwurfs. Und noch mehr, es hat einen spezifischen Namen: Entity-Attribut-Value (EAV). Es gibt einige Fälle, in denen dieses Design gerechtfertigt ist, aber das sind seltene Fälle - und auch dort kann es vermieden werden.

Warum EAV ist schlecht

Datenintegritätsunterstützung

Trotz der Tatsache, dass eine solche Struktur "flexibler" oder "fortschrittlicher" zu sein scheint, hat dieses Design Schwächen.

• Es ist nicht möglich, obligatorische Attribute zu erstellen . Sie können einige Attribute nicht zwingend machen, da das Attribut jetzt als Zeile gespeichert wird - und das einzige Zeichen, dass dieses Attribut nicht gesetzt ist - ist, dass die entsprechende Zeile in der Tabelle fehlt. SQL erlaubt es Ihnen nicht, solche Constraints nativ zu erstellen - also müssen Sie dies in der Anwendung überprüfen - und, ja, fragen Ihre Tabelle jedes Mal ab
• Mischen von Datentypen Sie können keine SQL-Standarddatentypen verwenden. Weil Ihre Wertespalte für alle darin gespeicherten Werte ein "Super-Typ" sein muss. Das bedeutet - Sie müssen im Allgemeinen alle Daten als rohe Zeichenfolgen speichern. Dann werden Sie sehen, wie schmerzhaft es ist, mit Daten wie mit Strings zu arbeiten, Datentypen jedes Mal umzuwandeln, die Datenintegrität zu überprüfen, e t.
• Unzureichende referentielle Integrität kann nicht erzwungen werden . Im Normalfall können Sie mit dem Fremdschlüssel Ihre Werte durch diejenigen einschränken, die in der übergeordneten Tabelle definiert sind. Aber nicht in diesem Fall, weil die referenzielle Integrität auf jede Zeile in der Tabelle angewendet wird, nicht jedoch auf Zeilenwerte. Also - Sie werden diesen Vorteil verlieren - und es ist einer der fundamentalen in Relation DB
• Attributnamen können nicht festgelegt werden . Das bedeutet - Sie können den Attributnamen auf DB-Ebene nicht korrekt einschränken. Zum Beispiel schreiben Sie im ersten Fall "customer_name" als Attributnamen - und ein anderer Entwickler wird das vergessen und "name_of_customer" verwenden. Und .. es ist in Ordnung, DB wird das passieren und du wirst mit Stunden fertig sein, die für die Fehlersuche in diesem Fall ausgegeben werden.

Zeilenrekonstruktion

Außerdem wird die Zeilenrekonstruktion im allgemeinen Fall schrecklich sein. Wenn Sie zum Beispiel 5 Attribute haben - das sind 5 Selbsttabellen JOIN -s. Schade für so einen einfachen - auf den ersten Blick - Fall. Daher möchte ich mir nicht einmal vorstellen, wie Sie 20 Attribute verwalten.

Kann es gerechtfertigt sein?

Mein Punkt ist - nein. In RDBMS wird es immer einen Weg geben, dies zu vermeiden. Es ist schrecklich. Und wenn EAV verwendet werden soll, dann ist die beste Wahl nicht relationale Datenbanken.

Im zweiten Fall (Tabelle 2) ist dies komplex und es braucht viel Zeit, um Daten zu finden, wenn wir eine Abfrage machen. Dieser Fall wird verwendet, wenn Sie nicht wissen über die Anzahl der Spalten oder sie sind unterschiedlich, wenn Sie feste Länge der Spalten dann ersten Fall (Tabelle1) verwendet haben, weil in diesem Fall Daten finden schnellen Weg.

Die Tabelle mit den Spalten id , name , age , birthdate und address ist das, was Sie verwenden, wenn Sie vor der Bereitstellung wissen, welche Informationen über eine Entität gespeichert werden sollen.

Die Tabelle mit den Spalten id , col_name , col_value kann verwendet werden, wenn Sie erst nach der Bereitstellung wissen, welche Informationen über eine Entität gespeichert werden sollen (z. B. wenn nichttechnische Personen in der Lage sein sollten, Felder zu definieren sie wollen erfassen). Es ist weniger effizient, aber Sie können neue Felder definieren, ohne das Datenbankschema zu ändern.