Nase schrieb:
Sinnigerweise sollte man es aber so machen, wie Daaron beschreibt.
"Sinnigerweise" wird es aber nur so gemacht, weil das relationale Datenmodell und die Normalformen es so fordern. Aus einem anderen Sichtwinkel betrachtet ist das relationale Datenmodell eigentlich das unsinnigste überhaupt. Denn unsere Datenmodelle in Programmiersprachen sind
Aggregierte Modelle, wir haben nicht einfach wie bei relationalen Datenbanken eine flate Datenstruktur, ein "Objekt" hat Unterobjekte, es hat Sets usw.
Somit muss immer eine Konvertierung zwischen objektorientierten Daten und der relationalen Datenbankstruktur stattfinden, es gibt einen
Impediance Mismatch.
Aber es einfach nur schlecht darzustellen, ist auch falsch. Denn die relationale Datenbank erlaubt einem damit die Daten so zu speichern, dass sie auf vielfache Weise durchsucht werden kann. Es bietet Safety-Checks (Datentyp der Spalte, CHECK Constraints, Foreign Keys usw..)...
Der Weisheit letzter Schluss sind weder relationale Datenbanken noch NoSQL-Datenbanken. Allerdings ist das von Daaron genannte
Dynamic Columns in MariaDb 5.3 (nicht v10) ein Schritt in die richtige Richtung, beides miteinander sinnvoll zu verschmelzen. Aber erst der Anfang (man kann keine Indexe nutzen). In PostgreSQL ist das auch als
Hstore- sowie
JSON-Erweiterung verfügbar. Mit der Möglichkeit sogar Indexe zu kombinieren und weiterhin die ACID-Kriterien einer relationalen Datenbank zu haben und nicht alles schemaless speichern zu müssen sondern nur eventuell wenige Attribute.
Meiner Meinung nach ist so ein dynamic columns Feature für tagging haargenau das richtige. Es wurde nur früher immer relational designed, weil es anders nicht möglich war.
Natürlich gehen auch serialisierte Arrays, aber imho taugt eine Lösung nichts, wenn ich keine Indexe dafür erstellen kann.
