Enums, Listen, in Datenbank speichern

[Rhönradfahrer (Gast)]

Wie speichert man denn in einem Spaltenattribut Dinge die 
unterschiedlich lang sind, z.B. Listeneinträge, Enumwerte,... Man könnte 
einen kommaseparieten String ablegen, den man dann wieder 
auseinanderklamüsert, oder man nimmt JSON,... gibts da was 
standardisiertes sowas wie einen Listen- oder Arraytyp für Spalten?

[Sebastian (Gast)]

Hi,

das Stichwort dazu wäre IMHO Normalisierung. Bei einem Enum (was eine 
1-n Beziehung ist) legst du eine zusätzliche Tabelle an mit z.B. den 
Spalten ID und Text. In die Ausgans-Tabelle trägst du dann die ID (als 
Foreign Key) ein.

Wenn du eine n-m Beziehung hast dann brauchst du zusätzlich noch eine 
weitere Tabelle in der die Beziehung gespeichert wird, jeweils durch die 
beiden IDs der anderen beiden Tabellen.

Bei Abfragen benutzt du dann einen entsprechenden Join um alle Inhalte 
komplett zusammen zu bekommen.

Greets,
  Sebastian.

[Rhönradfahrer2 (Gast)]

Ist viel zu umständlich wenn das nur ein Attribut einer Entität ist, vor 
allem wenn die Werte bei jedem Record anders sind. Wenn da mal 2 von 
1000 der Listenelemente, Enums,.... gleich sind lohnt das den Aufwand 
überhaupt nicht.

Gefunden:
Es gibt auch ENUM, SET und JSON in MySQL, wusste ich gar nicht.

[🐧 DPA 🐧 (Gast)]

Enum und set sind ja recht simpel, kann DB intern eine Nummer sein, die 
sind teils schon OK / Sinvoll. JSON sind strukturierte Daten, das ist 
nur selten sinvoll. Wenn man irgend eine Konfig in der DB ablegt oder 
so, ok, dann lohnt sich Normalisierung nicht wirklich. Aber in den 
meisten fällen, wenn man wirklich viele Einträge des selben typ hat, wie 
meistens wenn man ne Datenbank braucht, ist Normalisierung klar zu 
bevorzugen.

So ein JSON Blob in der DB ist weit weniger mächtig, als saubere DB 
Tabellen.
Zunächst mal zum Fundamentalen, zu den Daten, die damit abbildbar sind. 
JSON ist ein Baum. DB Tabellen bilden ein Graph. Letzteres kann 
Rekursionen usw. abbilden, ersteres nicht.
Und dann sind da all die anderen Sachen, die eine saubere DB Struktur 
dir gewährleisten kann. Du kannst sicherstellen, dass keine Einträge / 
Felder, usw., doppelt sind. Du kannst Constraints erfassen, was für 
daten erlaubt sind oder nicht. Du kannst sicherstellen, das 
referenzierte Elemente vorhanden sind, nicht gelöscht werden können, 
oder beim löschen die Referenz nullen, oder die referenzierenden 
Entitäten mitlöschen lassen, je nach Anwendungsfall.
Mit Indexen kann das suchen beschleunigt werden. Und du kannst daten 
beliebig Kombinieren und Aggregieren, um direkt in der DB beliebigste 
Auswertungen zu machen. Es gibt auch Views, die DB Queries sowas wieder 
als Tabellen anzeigen.
Und man sieht auch gleich, was für Felder / Daten es gibt, und was wie 
zusammenhängt. Bei Abfragen weiss man dann im vornherein, was man da 
bekommt, und erlebt keine Überraschungen.
Und dann hat man noch Transaktionen, um an mehreren Datensätzen 
konsistent Änderungen zu machen, was durch all das oben massiv einfacher 
wird.

Wenn du die Daten nur in einen JSON Blob packst, gehen so ziemlich all 
diese Vorteile flöten.