SQL Design: User Settings

[mental.dIseASe]

Meine relationale Denke (und weil ich's immer so gemacht habe ) würde mir die Konstellation User <- Einstellungswert -> Einstellung diktieren, also mit drei Tabellen. In der Software, die ich warte, ist in der Einstellungstabelle inzwischen soviel Krempel beigeordnet (Einstellungstypen, Validatoren und deren Constraints, Angaben in welcher Hierarchiestufe von Anwendern die gültig sind, Default-Werte und anderes), dass es unpraktikabel wäre, das alles mit in den User zu drücken oder in der Anwendungslogik abzufackeln.

 

[BeBur]

dass es unpraktikabel wäre, das alles mit in den User zu drücken oder in der Anwendungslogik abzufackeln.

Was spricht gegen einen table "settings" mit einer 1:1 Beziehung zum users table?

 

[RalphS]

Naja, extra Settingstabelle ist ja nicht per se schlecht. Nur aufwendiger. Gemäß Konfiguration von @mental.dIseASe ist mxn sogar die angenehmere Option... wenn auch zunächst erstmal auf Basis von, so ist es jetzt implementiert.

Wenn da noch jede Menge Attribute zu den Einstellungen kommen - welches Settingformat(Check,Radio,...) welcher Wertebereich, Validierung etc — kann man sicher auch per constraints und Datentypen im dbms abfackeln, aber je komplexer, desto schwieriger.

Eins höher gehen kann man beim Design praktisch immer. Wird nur irgendwann unhandlich. Aber hier und dort, warum nicht. Besser als irgendwann

create table t2 as select * from t1

sagen zu wollen.

 

[BeBur]

Naja, extra Settingstabelle ist ja nicht per se schlecht. Nur aufwendiger. Gemäß Konfiguration von @mental.dIseASe ist mxn sogar die angenehmere Option... wenn auch zunächst erstmal auf Basis von, so ist es jetzt implementiert.

Das Argument ist ja: Er würde X machen. Lösung Y hat Nachteile a und b.
Hier wurde aber insbesondere Lösung Z (1:1) genannt, welche Nachteile a und b nicht hat.
Ein Argument gegen X wurde ja schon genannt (es ist schwieriger, default Werte zu verwalten).

 

[mental.dIseASe]

Was spricht gegen einen table "settings" mit einer 1:1 Beziehung zum users table?

Ich bin kein Freund von JSON in Datenbanken, rational erklären kann ich das nicht. Für Metadaten einzelner Einstellungen wäre das auch irgendwie Käse. Letztlich ist es aber eine Frage des individuellen Geschmacks und seiner konkreten Anforderungen.

 

[BeBur]

Mit JSON hat das nichts zu tun.
1:1 heißt das es einen table 'users' gibt und einen table 'settings' mit einem unique fk 'user_id'.

Ich kann dir aber sagen was dagegen spricht JSON zu benutzen ;-). Du verlierst damit diverse Vorteile der DB. Trigger/Views/Constraints gehen nicht oder nur eingeschränkt (imHo und jedenfalls abhängig vom DBMS), selbst wenn man den heutzutage zuweilen verfügbaren Datentyp JSON wählt (MySQL / PostgreSQL hat sowas jdfs.) . Mal davon abgesehen, dass man sich auf einmal mit einer halb-anderen DSL rumschlägt.