SQL Datenorganisation

[hustbaer]

Ach das kann man so oder so machen. Bei > 100 Spalten ist halt klar dass die Sache recht unübersichtlich wird. Dafür hat man den Vorteil dass der Zugriff schneller ist und vor allem auch dass man den Fall "mir fehlt ein Wert" nicht behandeln muss -- weil es den Fall einfach nicht gibt.

Weiters ist es einfacher zu joinen falls das mal nötig werden sollte. Umgekehrt ist es aber schwer z.B. sowas zu machen wie alle Values die NULL sind aufzulisten.

Auch wäre interessant ob die Key/Value Paare alle "vergleichbar" sind. Also angenommen das sind "Key => Value" Paare wie z.B. "0°C => RGB(0, 0, 255)", "5°C => RGB(0, 20, 255)", "10°C => RGB(0, 40, 255)", ... dann würde ich eher zu einer Zeile pro "Key => Value" Paar tendieren.

Da du den Kontext nicht weiter beschreibst, könnte ich dir da keine konkrete Empfehlung geben.

[*john 0]

Wenn wir über ein RDBMS reden dann ganz klar nicht A, das ist Missbrauch eines RDBMS. Dann schon eher unterschiedliche Tabellen für die unterschiedlichen Keys.

[Belli]

Was john-0 sagt!
Ist das nicht auch total unflexibel, die Tabelle zu ändern, wenn keys hinzukommen/wegfallen?

Auf die Idee A wäre ich im Leben nicht gekommen

[Jockelx]

Ich verstehe immernoch nicht, was jetzt das besondere hier ist...
Alle Items haben die selben "Keys" (also klassisch "Spalten").
Das mal(*) eine weitere Spalte zu einerTabelle hinzugefügt wird ist jetzt auch nichts besonderes.

(*) Wie oft ist mal?

Also geht es nur um die hohe Anzahl der Spalten?

[Jockelx]

@john-0 sagte in SQL Datenorganisation:

Wenn wir über ein RDBMS reden dann ganz klar nicht A, das ist Missbrauch eines RDBMS. Dann schon eher unterschiedliche Tabellen für die unterschiedlichen Keys.

Was ist daran Missbrauch?
Ich habe zig Datensätze, die alle die identischen Keys "Name" und "Strasse" haben. Ist das jetzt Missbrauch das in eine Tabelle zu packen?

[5cript]

A ist nicht sinnvoll wenn:

• Nicht alle einträge für jeden Key ein value brauchen
• Wenn im Laufe des Lebens der DB immer mal wieder keys dazukommen.
• Wenn die Anzahl spalten groß wird.

A ist sinnvoll wenn:

• Man häufig nach values by key sucht.

Prinzipiell bevorzuge ich es wenn meine Tabellen fix sind, nach der ersten Erstellung.

[*john 0]

@Belli sagte in SQL Datenorganisation:

Was john-0 sagt!
Ist das nicht auch total unflexibel, die Tabelle zu ändern, wenn keys hinzukommen/wegfallen?

Die Normalisierung ist natürlich die zu bevorzugende Lösung. Aber bevor man die Tabelle beständig erweitert, ist das ggf. die weniger schlechte Lösung.

[Jockelx]

@john-0 sagte in SQL Datenorganisation:

Die Normalisierung ist natürlich die zu bevorzugende Lösung.

Ja. Wo ist A) nicht normalisiert?

[Martin Richter]

1. Für mich wäre es auch eine Frage wie oft und wahrscheinlich es ist, dass neue Key/Value Paare hinzukommen.
   Ist das ganze relativ statisch dann ist A eine gute Lösung.
2. Eine weitere Frage wäre ob Key/Value Paare untereinander in Relation stehen. Also Abhängigkeiten vorhanden sind oder gebildet werden müssen.
   Dann kann sowohl A als auch B ein Vorteil sein je nachdem...
3. Wenn Kreuztabellen gebildet werden müssen ist B natürlich klar vollzuziehen.

[DocShoe]

Viel mehr Kontext kann gibt´s da wirklich nicht. Die key/value Paare sind Konfigurationseinstellungen einer Software, von denen verschieden viele leer sind. Die Einträge sind vollkommen isoliert und stehen in keiner Relation zueinander. Pro Konfigurationsdatensatz sind unterschiedliche Spalten leer.
Wenn sich Konfigurationsparameter ändern (kommt ein paar Male pro Jahr vor, wenn Einstellungen für neue Features gebraucht werden), müssen Tabellenspalten ergänzt werden.

[SeppJ]

Kontext ist aber alles, denn du möchtest ja dein System korrekt modellieren. Hier klingt das mit dem Kontext nach einem klaren Fall für Modell B. Modell A spiegelt das System nicht korrekt wieder (viele Einträge leer, warum sind sie dann da?), und nagelt dir indirekt den jetzigen Parametersatz fest (man muss die Tabellenstruktur ändern, wenn neue Parameter hinzukommen oder wegfallen, und die Software funktioniert nicht korrekt, wenn Programmversion und Tabellenstruktur nicht in sync sind), wenn man doch annehmen sollte, dass so etwas wie ein Parametersatz eigentlich sehr flexibel in der Softwareentwicklung sein sollte.

Mit anderem Kontext kann hätte es auch durchaus gute Gründe für Methode A geben können.

[Ein ehemaliger Benutzer]

@DocShoe sagte in SQL Datenorganisation:

Konfigurationseinstellungen einer Software

Da käme mir auch noch C) XML- oder JSON-Datentyp in den Sinn.

[*john 0]

@Jockelx sagte in SQL Datenorganisation:

Ich habe zig Datensätze, die alle die identischen Keys "Name" und "Strasse" haben. Ist das jetzt Missbrauch das in eine Tabelle zu packen?

Wenn Du nach Schema-F das in die DB reinpumpst – ja. Wenn Du Felder „Name“ und „Strasse“ anlegst – nein. Ein RDBMS lebt davon, dass es Relationen zwischen den Tabellen gibt, und das untergräbst Du, wenn Du hier einfach keys und values in das RDBMS abkippst.

[DocShoe]

@manni66
Ja, wir wollen das allerdings unabhängig vom DBMS machen und JSON/XML hat´s, soweit ich weiß, noch nicht in den SQL Standard geschafft. SQL Server, Postgres und MySQL können mit JSON umgehen, da könnte man das versuchen. Ich habe grad nur kurz gesucht, aber es scheint so, als könnten die drei auch in JSON Dokumenten suchen, was eine der Anforderungen ist.

[Ein ehemaliger Benutzer]

@DocShoe sagte in SQL Datenorganisation:

JSON/XML hat´s, soweit ich weiß, noch nicht in den SQL Standard geschafft

Doch, aber die verschiedenen Implementierungen weichen davon natürlich wie immer nach gutdünken ab.

[DocShoe]

@manni66
Das macht ja nix, kann man ja per Stored Procedures erschlagen. Muss mich da mal schlau machen.