Archief - MySQL: Database modellering hulp gevraagd

Mijn database draait al een tijdje, maar omdat die nu "al" 1.8 mb groot is, vroeg ik mij af of het niet beter zou zijn meer met indextabellen enzo te werken (Dus meer joins):

Neem nu de volgende tabel:
post-id = int(10)
categorie = enum
type = enum
titel = varchar(255)
post = text
poster_id = mediumint(8)
datum = int(11)
rating_count = smallint(5)
rating = smallint(5)
rating_proc = tinyint(3)
rater_id = text
views = smallint(5)
laatstereactie = int(10)
aantal_reacties = smallint(5)
blokkeer = tinyint(1)

Wat als ik daar nu meerdere tabellen van maakte:

tabel categorie:
categorie_id
categorie_naam

tabel type:
type_id
type_naam

tabel post_index
post_id
categorie_id
type_id
titel
poster_id
datum
rating_count
rating
rating_proc
rater_id
views
laatstereactie
aantal_reacties
blokkeer

tabel post_text
post_id
post

(Of iets anders, stel maar voor...)

Welke gevolgen heeft dit voor de snelheid én de grootte van de database?

Bedankt

de grootte gaat sowieso al iets groter zijn dan een enkel tabel ( je moet immers link-velden maken tussen de 2)

de performantie zou wel eens kunnen stijgen als je aparte tabellen gebruikt, want dan hoeft mysql telkens maar te zoeken in kleinere tabellen.

Je moet natuurlijk er ook op letten dat je niet te veel opsplitst of anders krijg je een tegengestelde werking.

Snelheid wordt ook bepaald daar velden die al dan niet een index hebben.

Ook het correct opstellen van queries kanje snelheid bepalen: enkel ophalen van de noodzakelijke velden in plaats van een sterretje te gaan gebruiken bij je selects.

Je kan best geen splitsing maken dunkt me.

Een categorie opsplitsen in een aparte tabel met twee velden is nog trager normaal gezien. Het kan de db wel verkleinen, maar de link is IN DE MEESTE GEVALLEN trager dan de niet-opgesplitste versie.

Waarvoor het wel handig zou kunnen zijn, is het opsplitsen van niet veelgebruikte velden en veelgebruikte velden. Hiermee bedoel ik dat als je bijvoorbeeld de velden 'title', 'views', ... veel gebruikt (zowel in de eigenlijke page als op het hoofdscherm bijvoorbeeld) en het veld 'post' bijvoorbeeld enkel op de eigenlijke page, dan kan je 'post' best afsplitsen.

Maar gaat het echt traag ?

BTW: wat veel doet:
SELECT * FROM ...
vervangen door:
SELECT id, titel, post, ... FROM ...

Enkel de nodige velden uit de db laden !

Nullius, kleine toevoeging: je hebt enkel en alleen gelijk ALS hij ze altijd tegelijk laadt (wat ook dom zou zijn). Als hij die gegevens vaak eens apart moet laden zal het zeer waarschijnlijk beter zijn ze te scheiden.
Daarom wordt bv. ook in de meeste fora de tekst gescheiden van andere zaken, tekst is veel om in te zoeken, dus moesten al die lange tekst-elementen moeten doorzocht worden enkel en alleen om de forums of topics te listen zou je het wel steken hebben.

Originally posted by Nullius
Je kan best geen splitsing maken dunkt me.

Een categorie opsplitsen in een aparte tabel met twee velden is nog trager normaal gezien. Het kan de db wel verkleinen, maar de link is IN DE MEESTE GEVALLEN trager dan de niet-opgesplitste versie.

Waarvoor het wel handig zou kunnen zijn, is het opsplitsen van niet veelgebruikte velden en veelgebruikte velden. Hiermee bedoel ik dat als je bijvoorbeeld de velden 'title', 'views', ... veel gebruikt (zowel in de eigenlijke page als op het hoofdscherm bijvoorbeeld) en het veld 'post' bijvoorbeeld enkel op de eigenlijke page, dan kan je 'post' best afsplitsen.

Maar gaat het echt traag ?

BTW: wat veel doet:
SELECT * FROM ...
vervangen door:
SELECT id, titel, post, ... FROM ...

Enkel de nodige velden uit de db laden !

Klik om te vergroten...

Kheb listing pagina's waar ik het volgende nodig heb

post-id = int(10)
type = enum
titel = varchar(255)
poster_id = mediumint(8) (join naar user tabel)
datum = int(11)
rating_proc = tinyint(3)
views = smallint(5)
aantal_reacties = smallint(5)
en laatstereactie = int(10) soms...

En de eigenlijke pagina's waar ik dit laad:

post-id = int(10)
categorie = enum
type = enum
titel = varchar(255)
post = text
poster_id = mediumint(8) (join naar user tabel)
datum = int(11)
rating_proc = tinyint(3)
views = smallint(5)
aantal_reacties = smallint(5)
blokkeer = tinyint(1)

Enkel bij posts raten heb ik

rating_count = smallint(5)
rating = smallint(5)
rating_proc = tinyint(3)
rater_id = text

nodig.

Dus keb nooit alles nodig....

"SELECT * FROM ...
vervangen door:
SELECT id, titel, post, ... FROM ..."

Da spreekt voor zich en doe ik dus al van int begin zo

En nee hij is nie traag, maar ik verwacht wel dat in de loop van de maanden/jaren er duizenden records gaan in staan, en dat het dan gaat vertragen...

Originally posted by -P|b-SqUeaLeR
En nee hij is nie traag, maar ik verwacht wel dat in de loop van de maanden/jaren er duizenden records gaan in staan, en dat het dan gaat vertragen...

Klik om te vergroten...

Dan moeten er echt al vele duizenden records instaan hoor voor je db echt traag begint te worden, en meestal zal je tegen dan wel al een cleanup of zo gedaan hebben.

categorie = enum
type = enum

Klik om te vergroten...

ik zou deze in 2 gelinkte tbl steken, als er een categorie of type bijkomt kan je de structuur van je tbl gaan aanpassen

rater_id = text

Klik om te vergroten...

wordt hier een getal ingevuld dat verwijs naar een andere tabel???
zoja ==> veranderen naar int dan kan je ze ook indexeren + geen overhead !!

datum = int(11)

Klik om te vergroten...

zou datum= datetime niet logischer zijn ?? dan kan je gebruik maken van de date/time functies van mysql

Originally posted by zero2one
ik zou deze in 2 gelinkte tbl steken, als er een categorie of type bijkomt kan je de structuur van je tbl gaan aanpassen

Klik om te vergroten...

Is toch niet veel werk? gewoon een extra optie aan die enum toevoegen

Originally posted by zero2one
wordt hier een getal ingevuld dat verwijs naar een andere tabel???
zoja ==> veranderen naar int dan kan je ze ook indexeren + geen overhead !!

Klik om te vergroten...

Een lijst van user_id's wordt daar ingevuld, gescheiden door komma's, om te voorkomen da 1 user meerdere keren kan stemmen. Dus int gaat niet... En wat is dat indexeren??

Originally posted by zero2one
zou datum= datetime niet logischer zijn ?? dan kan je gebruik maken van de date/time functies van mysql

Klik om te vergroten...

in men phpBB tabellen staat de post-datum als int(11) dus ebbek da ook maar gedaan voor de rest.
kgebruik echo strftime("%A %e %B %Y - %H:%M",$post['datum']);
en echo date("d-m-'y",$post['datum']); en da marcheert ook.

Welke date/time functies bestaan der mss?

killgore zei:

Dan moeten er echt al vele duizenden records instaan hoor voor je db echt traag begint te worden, en meestal zal je tegen dan wel al een cleanup of zo gedaan hebben.

Klik om te vergroten...

Als je inderdaad al aan de duizenden records zit, zelfs dan gaat ie niet traag gaan op een goeie server.
En als je dan aan de tienduizenden zit, kan je beter een soort archief inbouwen, zodat het archief (dat wellicht VEEL minder gebruikt zal worden) misschien ietsje trager gaat, maar de page met recente posts niet.

Dus maak een functie die af en toe posts verplaatst naar een archief-table, zo blijft de hoofdtabel snel en overzichtelijk en heb je je archief om oudere posts bij te houden.

En elke table wordt op een server als aparte file opgeslagen (mysql), dus de db zelf kan niet vertragen.

Geen problemen dus