[SQL] Innerjoin en performance op persoons-tabel

[Verwijderd]

Ik heb een referentietabel gemaakt welke in een andere tabel gegevens van een product erbij zoeken.

Het is opzich vrij simpel:

persoon	kent_persoon
1	3
2	3
3	1
2	1

Hierbij hoort een tabel waar in personen staan met ID's 1 tm/3

Ik dacht aan een INNER JOIN om de namen van de personen weer te geven als ik alle kennissen van persoon 2 zou willen weergeven.

De vraag is per defenitie of dit bij echt honderden records traag gaat worden. Ik kan natuurlijk ook bij iedere persoon in de persoons-tabel een kennissen kolom maken en hierin een array maken van alle userid's welke de persoon kent. Ook dit kan traag worden wellicht.

Hoe is jullie idee over performance in een dergelijke referentie tabel als je over honderden tot duizenden records gaat praten ? bijvoorbeeld 500 per persoon ?

Dat soort setups zijn altijd tricky, maar ik kan weinig vinden aan de hand van opensource community scripts over performance, aangezien dit hetzelfde doet eigenlijk.

[RobIII]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:28:
De vraag is per defenitie of dit bij echt honderden records traag gaat worden.

Waarom bench je het niet? (En nee, "honderden" records zijn voor ieder zichzelf respecterend RDBMS peanuts, zeker als je de juiste indexes maakt en gebruikt).

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:28:
Ik kan natuurlijk ook bij iedere persoon in de persoons-tabel een kennissen kolom maken en hierin een array maken van alle userid's welke de persoon kent. Ook dit kan traag worden wellicht.

Reken maar dat 't traag wordt Lees eens wat over normalisatie

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:28:
Hoe is jullie idee over performance in een dergelijke referentie tabel als je over honderden tot duizenden records gaat praten ? bijvoorbeeld 500 per persoon ?

Again: bench het gewoon eens? Mikker je tabel vol met random records

Kleine opmerking terzijde: Als 1 -> 3 kent, waarom zou je dan nog 3 -> 1 opslaan? Ik neem aan dat ze elkaar andersom dan ook kennen?

[ Voor 6% gewijzigd door RobIII op 08-10-2009 18:35 ]

[Dido]

Je vraagt dus eigenlijk of een relationele database geschikt is om als relationele database te gebruiken?

Dit soort set-ups is exact waar het voor bedoeld is. Een paar duizend records is peanuts, en die join zal wel performen, hoor. Op voorwaarde dat je joint op een geindexeerd veld, natuurlijk, maar dat lijkt me voor de hand liggen als je het over een user-id hebt.

[Verwijderd]

Het maakt niet uit of je het over 1, 500, 50.000 of 5.000.000 hebt, als je je primary key maar over allebei de kolommen instelt.

Het is altijd "fout" om kommagescheiden waarden in een kolom op te slaan. Lees eens een boek over databases en normalisatie.

[edit]
Ben je je ervan bewust dat er [PHP] in de topictitel staat?

[edit 2]
@hieronder: uiteraard

[ Voor 17% gewijzigd door Verwijderd op 08-10-2009 18:35 ]

[RobIII]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:33:
Het maakt niet uit of je het over 1, 500, 50.000 of 5.000.000 hebt, als je je primary key maar over allebei de kolommen instelt.

Compound key van maken inderdaad

[Verwijderd]

Zoals jullie kunnen lezen heb ik niet voor niets een relationele tabel gemaakt, ik hoef dus niet nogmaals te gaan lezen over die komma gescheiden array

Het ging me er even om hoe het performt als je echt 1000-en records hebt. Jullie geven zelf ook al aan dat het prima gaat en dan kan ik zeker een bench gaan draaien wat uiteraard de bedoeling is

Vaak heb je 3 tabellen met een referentie, aanegezien ik van tabel 2 naar 1 ga had ik het idee dat dat opzich een performance issue kon worden en dat ik data nog anders moet gaan scheiden.

Toch de goede kant op dus

[Verwijderd]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:39:
Zoals jullie kunnen lezen heb ik niet voor niets een relationele tabel gemaakt, ik hoef dus niet nogmaals te gaan lezen over die komma gescheiden array

Het feit dat je de vraag stelt zegt meer dan genoeg

Het ging me er even om hoe het performt als je echt 1000-en records hebt.

Daar lacht een DBMS om.

Vaak heb je 3 tabellen met een referentie, aanegezien ik van tabel 2 naar 1 ga had ik het idee dat dat opzich een performance issue kon worden en dat ik data nog anders moet gaan scheiden.

Dat is het hele idee van een index.

[Verwijderd]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:43:
[...]

Het feit dat je de vraag stelt zegt meer dan genoeg

Tja, dat je de opmerking moet maken opzich ook... domme vragen bestaan niet als je het zeker voor het eventuele onzekere wil.

Als jij liever op je bek gaat door het altijd beter te weten be my guest, maar die discussie hadden we al eens gevoerd

Je kan zeggen dat een DBMS er om kan lachen, totdat hij het echt zwaar krijgt omdat de data structuur in combinatie met queries bij bepaalde load toch niet echt optimaal was... tja en dan ben je al telaat en dat wil ik niet

[RobIII]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:46:
Tja, dat je de opmerking moet maken opzich ook... domme vragen bestaan niet als je het zeker voor het eventuele onzekere wil.

With all due respect, seriously, maar als je een beetje iets van normaliseren en DB's af weet had je geen "arrays" voorgesteld

I know your little 4th grade teacher said there are no stupid questions. She was wrong. _{This is the internet}

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:46:
Je kan zeggen dat een DBMS er om kan lachen, totdat hij het echt zwaar krijgt omdat de data structuur in combinatie met queries bij bepaalde load toch niet echt optimaal was... tja en dan ben je al telaat en dat wil ik niet

Again: als je de materie beheerst weet je dat 't geen probleem is en dat 't JUIST goed is en zo hoort.

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:39:
Jullie geven zelf ook al aan dat het prima gaat en dan kan ik zeker een bench gaan draaien wat uiteraard de bedoeling is

Ik zie niet waarom je dit niet gewoon even kon benchen voordat je de vraag stelde. Was dat zoveel moeite dan?

[ Voor 22% gewijzigd door RobIII op 08-10-2009 18:55 ]

[DamadmOO]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:46:
[...]
Je kan zeggen dat een DBMS er om kan lachen, totdat hij het echt zwaar krijgt omdat de data structuur in combinatie met queries bij bepaalde load toch niet echt optimaal was... tja en dan ben je al telaat en dat wil ik niet

Zolang er geen performance probleem is is er geen reden om van fatsoenlijke normalisatie af te stappen. Als je wel een performance probleem hebt is het tijd om te kijken of dit komt door iets wat toch beter geoptimaliseerd kan worden of dat de hardware misschien niet meer voldoet.

Als ik bij elk ding wat ik doe me moet afvragen of het ooit misschien een performance probleem kan vormen dan komt er ook niks meer af. Dit is naturlijk geen vrijbrief om maar niet een fatsoenlijke testpopulatie op te zetten en daarmee te testen tot hoeveel records de load acceptabel is. Maar dat is bij 95% van de queries altijd het geval zolang je maar fatsoenlijk normaliseerd.

[Verwijderd]

RobIII schreef op donderdag 08 oktober 2009 @ 18:50:
[...]

With all due respect, seriously, maar als je een beetje iets van normaliseren en DB's af weet had je geen "arrays" voorgesteld

Ik zag een kleine tijd geleden een stuk recente code ergens tijdens een zoekactie naar wat anders en zag het daar ook en dit viel me op als "vreemd". De code bleek echter best op wat grotere schaal gebruikt te worden bleek

[...]

Again: als je de materie beheerst weet je dat 't geen probleem is en dat 't JUIST goed is en zo hoort.

Bovenstaand kan best eens verwarrend zijn. Zoals ik aangaf bemerkte ik het al, echter waarom zou je het niet vragen als je het normaal gesproken via een referentietabel doet en dit toch ineens terug ziet komen.

Kan de code wel direct af gaan z**ken, maar dat was niet m'n bedoeling

[momania]

Verwijderd schreef op donderdag 08 oktober 2009 @ 18:46:
[...]
Je kan zeggen dat een DBMS er om kan lachen, totdat hij het echt zwaar krijgt omdat de data structuur in combinatie met queries bij bepaalde load toch niet echt optimaal was... tja en dan ben je al telaat en dat wil ik niet

Daar hebben ze de explain plans voor bedacht Kan je zien hoeveel een query 'kost'.
Doe je je indices goed, dan hou je kosten laag en maakt het niet uit hoeveel records erin staan.

En duizenden records is echt peanuts voor een database. Bij tientallen miljoenen begint hij pas een beetje te zweten, maar hoort het nog niet echt zwaar te hebben

Verder als je wil weten hoe iets zich gaat gedragen en je wilt het zeker weten: TESTEN!
Dump die database maar vol met random data en test je query.

[Verwijderd]

momania schreef op donderdag 08 oktober 2009 @ 18:53:
[...]
Verder als je wil weten hoe iets zich gaat gedragen en je wilt het zeker weten: TESTEN!
Dump die database maar vol met random data en test je query.

Dat altijd !

Dank je

[cariolive23]

Wanneer je wilt weten of een query performance problemen kan krijgen, zorg dan eerst voor een bruikbare dataset. Een query loslaten op een tabel met 1000 records, is totaal wat anders dan een query op 100.000 records of op 100.000.000 records. Zorg dus voor een paar realistische doelen en ga daarop testen, configureren, indexen aanmaken, etc. etc. etc. Er zijn tientallen zaken die invloed hebben op de performance van één enkele query, zorg dus eerst voor een duidelijk doel zodat je dit doel uiteindelijk ook kunt bereiken.

En vergeet niet dat er meerdere users gelijktijdig de database kunnen benaderen en elkaar dus flink in de weg kunnen zitten bij het uitvoeren van de queries... Jouw server heeft maar één portie IO, één portie RAM, etc. en die moeten dus worden gedeeld.

[YopY]

Kort samenvattend: Je hebt regels voor normalisatie en dergelijke. Als je zeker weet dat je je daaraan houdt, dat je indexes goed zijn, dat je code die het verwerkt goed zit etc en je krijgt performanceproblemen, dan is het tijd voor betere hardware.

imo moet performance nooit een reden zijn om van normalisatie af te stappen. En zelfs als je performance problemen krijgt, kun je caching toepassen om dit weer te verlichten - het heeft immers weinig nut om voor elk request van een profielpagina (oid) alle vrienden van de gebruiker weer op te halen als deze niet veranderd zijn. Een beetje databasesoftware doet dit zelf natuurlijk, maar toch.

Maar dat is allemaal van later zorg. Als je een goed ontwerp / normalisatie doet in het begin, dan komt het wel goed.

Hoedt je ook voor premature optimization, btw.

[Woy]

YopY schreef op vrijdag 09 oktober 2009 @ 16:13:
Kort samenvattend: Je hebt regels voor normalisatie en dergelijke. Als je zeker weet dat je je daaraan houdt, dat je indexes goed zijn, dat je code die het verwerkt goed zit etc en je krijgt performanceproblemen, dan is het tijd voor betere hardware.

Daar ben ik het niet mee eens. Als je tegen performance problemen aanloopt kan weloverwogen denormalisatie best een oplossing bieden. Altijd maar zeggen dat je maar betere hardware nodig hebt is ook een beetje een dood-doener.

Hoedt je ook voor premature optimization, btw.

Dat wel natuurlijk!!!

[ Voor 7% gewijzigd door Woy op 09-10-2009 16:36 ]

[Confusion]

YopY schreef op vrijdag 09 oktober 2009 @ 16:13:
imo moet performance nooit een reden zijn om van normalisatie af te stappen.

Even iets sterker dan Woy: performance is juist bij uitstek een reden om van volledige normalisatie af te stappen.

En zelfs als je performance problemen krijgt, kun je caching toepassen om dit weer te verlichten

Je kan cachen wat je wilt: als de achterliggende query 100s kost, dan heb je een probleem dat alleen in de DBMS op valt te lossen.