Hoe settings opslaan in een database

De stringlengte is ook een integer, dus je kunt:

setting_varchar_min (minimale lengte)
setting_varchar_max (max lengte)
setting_int_min
setting_int_max

vereenvoudigen tot:

setting_min
setting_max

Waar ik over twijfel, is of je nog een tabel setting_types zou moeten toevoegen. De verschillende typen van iets apart opslaan, maakt het geheel vaak beter schaalbaar en toekomstbestendig, maar misschien heb je dat in jouw opzet helemaal niet nodig.

Verder zou ik een andere kolomvolgorde aanhouden:

• PK
• FKs
• kolommen met vaste lengten
• kolommen met een variabele lengte

ipv setting_description >> setting_label (dan komt het overeen met de HTML-tags)
setting_type >> bool CHAR/INT/DATE
setting_req >> BOOL true/false (is 1/0)
setting_varchar_min >> je gaat er een getal in stoppen? INT
setting_varchar_max >> je gaat er een getal in stoppen? INT dus, al kan je prima de naam zo ouden

setting_varchar: lijkt mij geheel niet nodig.
Net als setting_int.

Je krijgt straks 2 tabellen:
1 met setting_settings (of zoiets)
1 met inhoud:

id | setting_id | user_id| value

De eerste ID kan in principe weg, omdat je setting_id + user_id toch al uniek is... Daar kan je dus ook je PRIMARY KEY of UNIQUE op maken.
Je kan bij je instelling "volume" (van geluid bijvoorbeeld) nog niet meer dan 1 instelling hebben.

Top, bedankt voor de feedback.
De min en max kan inderdaad in 1, hoeft niet per type.
Apart type tabel neem ik mee in de overweging, goede suggestie maar inderdaad waarschijnlijk is het bij dit project niet nodig.
@Eddy Ik wil de de types int en varchar wel gescheiden houden omdat er berekeningen gedaan worden in de query.

Maar dan komt mijn volgende vraag, stel je voor ik doe het zo met 2 aparte tabellen voor de setting waardes (setting_varchar, setting_int) kan ik dat ophalen in 1 query met een soort van if/else?

SELECT * FROM settings AS s, (if s.setting_type == 1 ? settings_varchar : settings_int) AS sv WHERE sv.setting_id = s.setting_id

Is zoiets mogelijk in sql?

Nee, je opzet is prima in orde, maar enkel het setting_varchar en setting_int is een slecht idee.
Waarom zou je dat scheiden? Een waarde is INT óf varchar en geef je aan met setting_type.

Eddy E op 23/10/2015 15:39:55

Waarom zou je dat scheiden?

Omdat ze met een ander sql data type gestored moeten worden. In het voorbeeld gebruik ik alleen int en varchar, maar hier kan bijv. nog een datum bijkomen en deze wil ik dan opslaan met bijv. een datetime type.

Eddy E op 23/10/2015 15:39:55

Een waarde is INT óf varchar en geef je aan met setting_type.

Dus dan vraag ik me af wat is beter, voor elk type een apart tabel, of een tabel met alle types, waarvan maar 1 veld ingevuld wordt.

#setting_value
setting_value_id
setting_id 
user_id
setting_varchar_value
setting_int_value
setting_date_value
enz.

Dat laatste klinkt mij dan het meest logisch. Al zal je dan wel overhead hebben omdat je maar 33% van de kolommen gebruikt.

" Al zal je dan wel overhead hebben omdat je maar 33% van de kolommen gebruikt."

NULL velden kosten 1 bit aan opslag dus de overhead van een leeg veld is te verwaarlozen.


"Is zoiets mogelijk in sql?"

Ja, met COALESCE(). Als je op de tabel een trigger zet die controleert dat altijd OF de int OF de varchar is ingevuld dan kun je de waarde opvragen met iets als :
SELECT naam, type, COALESCE(int_veld, char_veld) AS data FROM ...

En als je dat netjes verwerkt in een view dan heb je er geen omkijken meer naar en kun je iets doen als SELECT * FROM view_settings;