Hoe settings opslaan in een database
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Setting
setting_id (pk)
setting_name
setting_description
setting_type (Type: 0 = varchar, 1 = int)
setting_req (Verplicht? 0=nee, 1=ja)
setting_varchar_min (minimale lengte)
setting_varchar_max (max lengte)
setting_int_min
setting_int_max
#setting_varchar
setting_varchar_id (pk)
setting_varchar_value
setting_id (fk)
user_id (fk)
#setting_int
setting_int_id (pk)
setting_int_value
setting_id (fk)
user_id(fk)
setting_id (pk)
setting_name
setting_description
setting_type (Type: 0 = varchar, 1 = int)
setting_req (Verplicht? 0=nee, 1=ja)
setting_varchar_min (minimale lengte)
setting_varchar_max (max lengte)
setting_int_min
setting_int_max
#setting_varchar
setting_varchar_id (pk)
setting_varchar_value
setting_id (fk)
user_id (fk)
#setting_int
setting_int_id (pk)
setting_int_value
setting_id (fk)
user_id(fk)
Ik heb de varchars en int waardes gescheiden omdat er met de int waardes nog gerekend moet worden.
Het users table heb ik niet genoemd maar user_id is uniek id van een user.
Iemand tips of opmerkingen over deze structuur?
Gewijzigd op 23/10/2015 14:08:16 door Gerhard l
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
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.
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?
Code (php)
1
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?
Gewijzigd op 23/10/2015 15:21:42 door gerhard l
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.
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
#setting_value
setting_value_id
setting_id
user_id
setting_varchar_value
setting_int_value
setting_date_value
enz.
setting_value_id
setting_id
user_id
setting_varchar_value
setting_int_value
setting_date_value
enz.
Gewijzigd op 23/10/2015 16:12:09 door gerhard l
Dat laatste klinkt mij dan het meest logisch. 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;