Wird in einem Longtext-Feld in MySQL ein beliebiger Typ (Integer, Text, Datum) gespeichert?

Question

Ich entwickle ein CMS mit Seiten/Posts, benutzerdefinierten Seiten/Posts und benutzerdefinierten Feldern. Diese benutzerdefinierten Felder werden über die Benutzeroberfläche ausgewählt und an eine benutzerdefinierte Seite angehängt.

Zum Beispiel erstellen wir eine benutzerdefinierte Seite/Post 'Projekt', die eine diese Felder haben: Beschreibung, Reihenfolge, Preis und Datum.

Ich möchte keine Tabelle für jeden Seitentyp verwenden, den ich habe, ich möchte nur eine einzige Tabelle verwenden, um jedes Feld eines jeden benutzerdefinierten Feldes zu speichern, das Problem ist, dass sie unterschiedliche Datentypen haben könnten. Meine Frage ist, ist es eine schlechte Idee (an Leistung denken), um z.B. der Bestellwert in einem generischen Longtext-Typ-Feld? Ist es besser, eine "customvaluestable" mit 3 Feldern (date, integer, text) zu erstellen, die den Wert des benutzerdefinierten Feldes abhängig von seinem Datentyp speichert und den Rest null lässt?

Dank

Answer 1

technisch gesehen, ist es eine schlechte Idee ... beide Ideen, eigentlich. Sie denken wahrscheinlich "Ich möchte die Tabellen nicht immer ändern", aber es gibt einige Implikationen: Die Suche nach Strings ist weniger effizient als die Suche nach Zahlen, Daten, ... Wenn Sie alles in ein Textfeld schreiben wollen, nicht nur Wird mehr Speicherplatz benötigt, werden alle Suchanfragen durchgeführt.

Was Sie sich fragen sollten, ist dies: Was ist es, was Sie eigentlich erreichen möchten? Wenn Sie möchten, dass zusätzliche beliebige Daten neben statischen Daten gespeichert werden, dass Sie nicht wie immer suchen werden ... json-codieren Sie diese Daten und legen Sie es einfach in ein Feld, das Sie "customdata" oder was auch immer nennen. Oder benutze zuerst einen nosql/keyvalue-store!

Wenn Sie danach suchen möchten, gehen Sie die extra Meile, schauen Sie sich an, wie drupal benutzerdefinierte Felder behandelt. Es ist hässlich, aber zumindest sind sie konsistent. Eine Nummer sollte in einem numerischen Feld gespeichert werden. (Weil die lexikographische Anordnung von Zahlen in Stringfeldern wirklich seltsam ist ...).

Answer 2

Sie könnten stattdessen MySQL 5.7 mit seiner neuen Unterstützung für eine native JSON data type stattdessen verwenden. Dann können Sie Ihre benutzerdefinierten Felder haben.

Das Design, über das Sie sprechen, heißt Entity-Attribute-Value model. Obwohl ich bestreite, dass es sich tatsächlich als ein Datenmodell qualifiziert.

Es gibt viele Probleme mit EAV, da es sich im Grunde um eine nicht relationale Lösung handelt, die in einer relationalen Datenbank implementiert ist.

Literaturhinweis:

• Bad CaRMa
• EAV FAIL
• Extensible Data Modeling with MySQL

Aber das Endergebnis ist, dass Sie im Grunde Ihr eigenes System von Metadaten über Ihre Spalten und Typen am Ende die Schaffung - Im Grunde, implementieren Sie Ihr eigenes Datenbank-Management-System in einem RDBMS, das viel Arbeit und Einführung erfordert s viele Bugs auf dem Weg. Dies wird die Inner-platform Effect genannt:

... die Tendenz der Software-Architekten ein System so individuell zu erstellen, wie eine Replik zu werden, und oft eine schlechte Replik, der Software-Entwicklungsplattform sie verwenden.