[SQL] Database Ontwerp

[didio]

Ik ben een beetje benieuwd hoe andere mensen dit doen.

Stel je hebt een tabel met echt veel columns plaats je die dan in 1 tabel of splits je dat op over meerdere tabellen?

[Verwijderd]

ligt eraan welke links je gaat leggen met die tabellen in je script...

[bigtree]

Het hangt er van af hoe veel van die kolommen je in de praktijk gebruikt. Stel je hebt 50 kolommen waarvan je er meestal maar 10 (dezelfde) kolommen gebruikt, zou ik die andere 40 in een andere tabel zetten.

[RRX]

Ik zou het gewoon in 1 tabel zetten, als je in je query gewoon

code:

SELECT collumnnmen FROM tabelnaam

dan laat je MySQL ook niet onnodig werken

[didio]

Op zondag 11 november 2001 19:16 schreef RRX het volgende:
Ik zou het gewoon in 1 tabel zetten, als je in je query gewoon

code:

SELECT collumnnmen FROM tabelnaam

dan laat je MySQL ook niet onnodig werken

Ik deed dit ook altijd, maar het word zo onoverzichtelijk als je 20 of meer columns heb. Vandaar mijn vraag of andere mensen dit ook op deze manier doen.

[Verwijderd]

Op zondag 11 november 2001 19:25 schreef didio het volgende:

[..]

Ik deed dit ook altijd, maar het word zo onoverzichtelijk als je 20 of meer columns heb. Vandaar mijn vraag of andere mensen dit ook op deze manier doen.

zoals ik al zei
je moet kijken welke tabellen je het vaakst met elkaar nodig hebt (session_id tabel met users tabel etc).
het ligt er maar net aan wat je wilt doen, en wat je wilt berijken

[didio]

Op zondag 11 november 2001 19:29 schreef ReaLX het volgende:

[..]

zoals ik al zei
je moet kijken welke tabellen je het vaakst met elkaar nodig hebt (session_id tabel met users tabel etc).
het ligt er maar net aan wat je wilt doen, en wat je wilt berijken

Nou het is eigenlijk meer data die in een tabel zouden kunnen, bijvoorbeeld een tabel met software, als je daar nou veel columns zou hebben zou je bijvoorbeeld alle data over de file zelf zoals de filenaam, filesize, en dat soort spul in een andere tabel kunnen zetten en die dan linken aan de hoofdtabel. Je moet dan wel weer met joins/views aan de gang om alles aan elkaar te knopen.

[Verwijderd]

Uit de faq : normaliseren

[didio]

Op zondag 11 november 2001 19:40 schreef Yarvieh het volgende:
Uit de faq : normaliseren

Ik werk natuurlijk altijd met relaties als het om bepaalde dingen gaat, als je bijvoorbeeld zoals in mijn voorbeeld categorien zou hebben ga je die natuurlijk niet in de zelfde tabel zetten. Het gaat dus meer om data die eigenlijk in dezelfde tabel thuishoort, maar omdat het misschien zo veel zou worden dat je het dan gaat scheiden in aparte tabellen.

[raptorix]

Op zondag 11 november 2001 19:16 schreef RRX het volgende:
Ik zou het gewoon in 1 tabel zetten, als je in je query gewoon

code:

SELECT collumnnmen FROM tabelnaam

dan laat je MySQL ook niet onnodig werken

Uh, dan moet je toch es wat lezen over databases en performance/tuning. Het is over het algemeen beter om een table te hebben met weinig columns omdat dit minder fysieke reads kost. Je moet maar eens in de enterprise tools van mysql kijken hoe dat zit met performanc

[RRX]

ik doe het uiteraard wel zo:

vb:

code:

+-----------+
|Tabel: Boek|
+--+----+---++---------+
|ID|naam|ISBN|auteur_ID|
+--+----+----+---------+

+-------------+
|Tabel: Auteur|
+--+-----+----++
|ID|vnaam|anaam|
+--+-----+-----+

zodat als ik bijv. 2 boeken heb van dezelfde schrijver, niet 2 * dezelfde schrijver hoef in te vullen.

[didio]

Op zondag 11 november 2001 19:57 schreef RRX het volgende:
ik doe het uiteraard wel zo:

vb:

code:

+-----------+
|Tabel: Boek|
+--+----+---++---------+
|ID|naam|ISBN|auteur_ID|
+--+----+----+---------+

+-------------+
|Tabel: Auteur|
+--+-----+----++
|ID|vnaam|anaam|
+--+-----+-----+

zodat als ik bijv. 2 boeken heb van dezelfde schrijver, niet 2 * dezelfde schrijver hoef in te vullen.

Maar dat is logisch natuurlijk..

[didio]

Op zondag 11 november 2001 19:56 schreef raptorix het volgende:

[..]

Uh, dan moet je toch es wat lezen over databases en performance/tuning. Het is over het algemeen beter om een table te hebben met weinig columns omdat dit minder fysieke reads kost. Je moet maar eens in de enterprise tools van mysql kijken hoe dat zit met performanc

Oke, dus het is beter als je toch een tabel overhoud met laten we zeggen 20 columns om dat dan op te splitsen in 2 tabellen..

[raptorix]

Op zondag 11 november 2001 20:02 schreef didio het volgende:

[..]

Oke, dus het is beter als je toch een tabel overhoud met laten we zeggen 20 columns om dat dan op te splitsen in 2 tabellen..

20 columns moet opzich wel te doen zijn voor de meeste databases, maar wat is beter? Je zult dan wat meer informatie moeten geven over wat je er in wilt stoppen, en hoeveel, of er vaak opgezocht moet worden, of je grote recordsets terug verwacht, daarnaast is het ook maar weer de vraag of je normale selects doet op alleen die tables of dat je ook weer joins gaat maken, en zelfs als je dit soort informatie allemaal weet dan nog kan het qua performance wel eens tegen vallen en moet je gaan kijken of er misschien andere manieren zijn om je database te optimaliseren.


Kennis over optimalisatie van databases kan je niet echt "leren" veel moet je gewoon hebben meegemaakt in de praktijk, misschien dat je daarom ook snapt dat goede dba's en dbd's zeldzaam zijn, ik ben er in een jaar of 6 maar een handvol tegengekomen en bij dat soort lui denk je zelf, heej ik ben er nog lang niet

[didio]

Op zondag 11 november 2001 20:16 schreef raptorix het volgende:
20 columns moet opzich wel te doen zijn voor de meeste databases, maar wat is beter? Je zult dan wat meer informatie moeten geven over wat je er in wilt stoppen, en hoeveel, of er vaak opgezocht moet worden, of je grote recordsets terug verwacht, daarnaast is het ook maar weer de vraag of je normale selects doet op alleen die tables of dat je ook weer joins gaat maken, en zelfs als je dit soort informatie allemaal weet dan nog kan het qua performance wel eens tegen vallen en moet je gaan kijken of er misschien andere manieren zijn om je database te optimaliseren.


Kennis over optimalisatie van databases kan je niet echt "leren" veel moet je gewoon hebben meegemaakt in de praktijk, misschien dat je daarom ook snapt dat goede dba's en dbd's zeldzaam zijn, ik ben er in een jaar of 6 maar een handvol tegengekomen en bij dat soort lui denk je zelf, heej ik ben er nog lang niet

Ik begrijp het, ik kan ook niet echt een voordeel opnoemen nou, het was meer een vraag voor als ik het eens nodig heb, ik kan me voorstellen dat veel columns zwaarder word voor de database maar veel met joins gaan werken ook wel weer. Ik werk al 2 jaar met SQL Server dus de meeste dingen weet ik wel, maar toch is performance altijd moeilijk iets..

[raptorix]

Als je met sqlserver werkt zou ik je zeker aanbevelen eens naar de profiler te kijken (als je dit nog niet deed) daarnaast kan het executie plan je ook veel informatie geven. Wil je echt verder er in duiken dan zou ik je van harte de cursus optimising en tuning sqlserver aanbevelen wordt gegeven door computrain. Niet goedkoop maar wel zeer de moeite waard.

[dusty]

goh.. nog een vrijdag middag topic op zondag...

[raptorix]

Op zondag 11 november 2001 22:32 schreef dusty het volgende:
goh.. nog een vrijdag middag topic op zondag...

We zijn niet allemaal zondags programmeurs