[SQL]Welke van de twee is sneller?*

[Verwijderd]

Ik zit met het volgende probleem, ik ben bezig met een projectje. (stelt niet veel voor en is eigenlijk het eerste wat ik doe met databases) Ik heb het resultaat al af en achteraf ga je je dan toch enkele dingen af vragen. (lees dus altijd meerdere boeken, en dan niet stukjes maar helemaal )

Het gaat me vooral om de snelheid van de database. Ik werk momenteel met MSSQL2000 en dat gaat vrij goed. Het probleem is nu echter dat het project achteraf nog is gaan groeien en ik dus nu liever voor een snelle database ga. Het begin was vrij simpel maar het wordt nu toch steeds groter.

Ik heb een database met daarin ongeveer 10 tabellen. Negen ven de 10 tabellen hebben niet meer als 5 kolommen. De tiende tabel echter zit nu al op > 20 kolommen. De data die in deze tabel staat heb ik in principe altijd nodig. Ik dacht er dus aan om de tabel op te delen in groepjes. (zoals b.v. maten, kleuren enz.) Dan zou ik dus gaan werken met een index. (en dus met zeg maar ding_ID gaan werken) De vraag is nu dus of het wel sneller is omdat ik de data toch bijna altijd nodig heb. (in meer als 70% van de gevallen) Dat is dus mijn probleem.

Ik heb de zoekfuntie al geprobeerd te gebruiken maar ik kwam er niet echt verder mee. (wel kwam ik [rml][ sql] Wat is sneller? Select * of Select <veld>, <veld>, ...[/rml] tegen waar ook wel wat leuke info in staat)

edit:

ikzelf maak me er eigenlijk niet zo druk om, want het werkt volgens mij snel zat, zit hier echter met collega's die het allemaal beter weten. (maar zelf niets doen uiteraard) De info is dus eigenlijk ook meer van belang voor komende klusjes.

[ Voor 12% gewijzigd door Verwijderd op 03-01-2003 02:46 ]

[SWINX]

doe een test

[Verwijderd]

SWINX schreef op 03 januari 2003 @ 03:08:
doe een test

Voor een test zou ik ze alle 2 moeten maken. (en dan zou ik nog geen idee hoe ik het kan testen op snelheid) En als iemand het hier weet is het makkelijker, en tevens beter omdat er hier nogal wat mensen zitten met meer ervaring als ik.

[klinz]

Je kunt natuurlijk van 'views' gebruik maken. Dan maak je een aantal views waarin je steeds van andere velden gebruik maakt.

[ Voor 8% gewijzigd door klinz op 03-01-2003 03:20 ]

[whoami]

Als je altijd alle data uit die tabel nodig hebt, dan is volgens mij 1 tabel sneller.
Data uit 1 tabel lezen is altijd sneller dan als je moet gaan joinen.

Trouwens, afaik is het niet het aantal kolommen die opgehaald worden die een query significant langzamer kan maken (natuurlijk, er moeten dan wel weer meer gegevens over het netwerk getransporteerd worden), maar is het vooral het aantal records in een tabel die een query kunnen vertragen. (Maar dat is dan wel weer op te lossen door goed gebruik te maken van (de verschillende types) indexen.

_{Titel gemod}

[Verwijderd]

ik neem aan dat de vraag uit je onderwerp is of je de MSDE gaat gebruiken of een SQL Server 2000?

ze hebben dezelfde engine en MSDE is een light versie van SQL Server

[Verwijderd]

whoami schreef op 03 January 2003 @ 10:36:
Als je altijd alle data uit die tabel nodig hebt, dan is volgens mij 1 tabel sneller.
Data uit 1 tabel lezen is altijd sneller dan als je moet gaan joinen.

Trouwens, afaik is het niet het aantal kolommen die opgehaald worden die een query significant langzamer kan maken (natuurlijk, er moeten dan wel weer meer gegevens over het netwerk getransporteerd worden), maar is het vooral het aantal records in een tabel die een query kunnen vertragen. (Maar dat is dan wel weer op te lossen door goed gebruik te maken van (de verschillende types) indexen.

_{Titel gemod}

Bedankt voor de titel mod. En het gaat om een database met nog geen 1000 records. Zal ook niet snel groeien, misschien elke week 3 a 4 records erbij.

[chem]

Ik zie het probleem niet zo?
De user-table van react kent 47 (!) kolommen, en zo'n 45 duizend records oid,

whoami heeft wel gelijk dat 1 table altijd sneller is dan een join. Maar, goed specificeren wat je wil hebben is ook nuttig.

[Verwijderd]

chem schreef op 03 januari 2003 @ 13:13:
Ik zie het probleem niet zo?
De user-table van react kent 47 (!) kolommen, en zo'n 45 duizend records oid,

whoami heeft wel gelijk dat 1 table altijd sneller is dan een join. Maar, goed specificeren wat je wil hebben is ook nuttig.

Ow dan is er geen enkel probleem meer. ik dacht alleen dat ik dan binnenkort een keer met snelheidproblemen kwam te zitten. Maar dat is dus niet zo, mensen bedankt.

[chem]

Het aantal kolommen is alleen een 'probleem' als het model niet meer klopt. Bijvoorbeeld: een online webshop voor computers met velden als cpu, kast, geheugen1, geheugen2, drive1, drive2, drive3, voeding
Dat is heel wat anders uiteraard

[Verwijderd]

chem schreef op 03 januari 2003 @ 13:24:
Het aantal kolommen is alleen een 'probleem' als het model niet meer klopt. Bijvoorbeeld: een online webshop voor computers met velden als cpu, kast, geheugen1, geheugen2, drive1, drive2, drive3, voeding
Dat is heel wat anders uiteraard

Jup, dat snap ik, hier zijn het wel echt verschillende dingen. B.v: prijs, lengte, gewicht enz.

[Verwijderd]

Je db klinkt niet bepaald groot. Alleen als je heel veel users hebt zou je een probleem kunnen krijgen.

Bij MSSQL zit "Query Analyser". Daarmee kan je timings bekijken en het executie pad. Daaraan kan je vaak goed zien waar de bottlenecks bij je queries zitten. Je krijgt dan een plaatje met alle onderdelen van je query en hoe lang ze duren om uit te voeren. Op basis daarvan kan je ook bepalen waar je het beste indexen kan toevoegen en evt. kan denormaliseren etc.

[Verwijderd]

Ik doe in Oracle, maar volgens mij zijn de basisregels ver hetzelfde.
Regel 1: "Thou shall not select more than thy need". Ofwel: NOOIT select *, ook al wil je alle kolommen selecteren. Dit vergroot ook de onderhoudbaarheid van je code (geen zin om uit te leggen).
Ander puntje: bij een paar duizend rijen zal je zelden problemen krijgen met performance. Mijn ervaring in Oracle is dat je in één tabel toch minstens vijfhonderdduizend rijen moet hebben, of bv joins van 3 tabellen van vele tienduizenden rijen, om enigszins performanceverlies veroorzaakt door slechte statements waar te kunnen nemen. De performance gaat exponentieel achteruit met toename van de schaalgrootte, vanzelfsprekend.

[robjanssen]

Datamodel technisch is het altijd beter om alle dingen die bij 1 item horen bij elkaar in een tabel te zetten.
Dus ik zou zeggen: Gebruik 1 tabel.

[Poiter]

Performance problemen zul je voorlopig niet hebben met zo'n kleine database. Tenminste als je logica er achter goed in elkaar zit. Ik maak zelf gebruik van tabellen met soms meer dan 50 kolommen en miljoenen records, waarbij query's binnen enkele seconden worden uitgevoerd. Vermijdt verder zo veel mogelijk joins en ingewikkelde query's, is slecht voor de performance en voor de onderhoudbaarheid van je code. Gebruik inderdaad de "Query Analyser" om je query's te bekijken, en hieruit kun je ook automatisch indexes laten maken. "Select * " mag je best gebruiken als dit handiger is (zeker als je vanuit een object-gedachte de zaak bekijkt), en performance problemen zal dat ook niet opleveren bij kleine projecten, als de index maar goed is.