[sql] optimalisatie vraag

[HenkS]

vraag:

als je bv select * from table where zichtbaar='j' and type='e' order by rangorde

als je dan de tabel wilt optimaliseren, wat kun ej dan het beste doen? op zichtbaar, type en rangorde ieder een aparte index zetten?? of wat is het beste? (is hele grote db)

of dus 3 aparte indexen, of 1 gezamelijke of een combinatie

wel moet er rekening mee worden gehouden dat er ook andere queries op die tabellen lopen waar alleen op zichtbaar='j' of alleen een order by erin zit

wat is dan het beste

[Verwijderd]

volgens mij, apart op TYPE en ZICHTBAAR en RANGORDE
en dat select * niet gebruiken

[Verwijderd]

Op woensdag 03 oktober 2001 15:44 schreef woeitje het volgende:
volgens mij, apart op TYPE en ZICHTBAAR en RANGORDE
en dat select * niet gebruiken

select * maakt in principe niet uit, je moet je alleen afvragen of je alle kolommen nodig hebt

aparte indexen op alle kolommen heeft niet veel zin.
Index op zichtbaar heeft geen zin : alleen J of N
Index op rangorde is niet nodig : order by gaat over gevonden records (dus nadat alle records die voldoen aan where opgehaald zijn)

[HenkS]

Op woensdag 03 oktober 2001 15:44 schreef woeitje het volgende:
volgens mij, apart op TYPE en ZICHTBAAR en RANGORDE
en dat select * niet gebruiken

zijn dat stopwoorden aan het worden hier op GOT? 'volgens mij' en 'ik denk dat' bij een antwoord zou het wel fijn zijn als mensen iets ZEKER weten. ik heb namelijk bij een optimalisatie niet iets aan een 'volgens mij'

verder geen persoonlijke kritiek maar een algemene, want het wordt wel ERG vaak gebruikt hiero

[drm]

Op woensdag 03 oktober 2001 15:52 schreef HenkS het volgende:

[..]

zijn dat stopwoorden aan het worden hier op GOT? 'volgens mij' en 'ik denk dat' bij een antwoord zou het wel fijn zijn als mensen iets ZEKER weten. ik heb namelijk bij een optimalisatie niet iets aan een 'volgens mij'

verder geen persoonlijke kritiek maar een algemene, want het wordt wel ERG vaak gebruikt hiero

Als ik geen "volgens mij" zou gebruiken, zou ik er morgen op afgerekend worden dat ik geen gelijk heb.
En ik denk dat dat vaker zo werkt.
//offtopic

[dusty]

Wat wel zin heeft is om je database model te verbeteren.

In plaats van zichtbaar J/N kan je beter 0/1 gebruiken ( gewoon een bit ) de database kan daar veel en veel beter mee omgaan dan met een letter.

Ik neem aan dat type's ook gelimiteerd is, zou ik zeggen los dat ook met een getal op!

En vooraan de where eerst de meest limiterende factor neerzetten, dus eerst op type selecteren DAN op zichtbaar.

[Annie]

Op woensdag 03 oktober 2001 15:52 schreef HenkS het volgende:

[..]

zijn dat stopwoorden aan het worden hier op GOT? 'volgens mij' en 'ik denk dat' bij een antwoord zou het wel fijn zijn als mensen iets ZEKER weten. ik heb namelijk bij een optimalisatie niet iets aan een 'volgens mij'

verder geen persoonlijke kritiek maar een algemene, want het wordt wel ERG vaak gebruikt hiero

Volgens mij is dat gewoon spreektaal wat gewoon in het forum ook gebruikt wordt.

Sowieso zijn er voor databases een aantal basisprincipes waar je vanuit kan gaan, maar dit is nooit de absolute oplossing. Zeker bij grotere databases zal je zelf adhv real-time tests moeten kijken wat de beste oplossing is.
Dus begin situatie meten, index(en) aanleggen, weer meten, eventueel bijsturen, enz, enz. Het komt nog wel eens voor dat een index op papier perfect zou moeten werken, maar in de praktijk toch niet de performance winst biedt die je eigenlijk gehoopt had.

[Verwijderd]

Op woensdag 03 oktober 2001 16:00 schreef dusty het volgende:
Wat wel zin heeft is om je database model te verbeteren.

In plaats van zichtbaar J/N kan je beter 0/1 gebruiken ( gewoon een bit ) de database kan daar veel en veel beter mee omgaan dan met een letter.

Ik neem aan dat type's ook gelimiteerd is, zou ik zeggen los dat ook met een getal op!

En vooraan de where eerst de meest limiterende factor neerzetten, dus eerst op type selecteren DAN op zichtbaar.

leuk discussiepunt

[dusty]

Op woensdag 03 oktober 2001 15:59 schreef drm het volgende:
Als ik geen "volgens mij" zou gebruiken, zou ik er morgen op afgerekend worden dat ik geen gelijk heb.
En ik denk dat dat vaker zo werkt.
//offtopic

So what als je een keertje fout zit? Iedereen maakt fouten, heel simpel, iemand die iemand anders daarop (serieus) afrekend is gewoon dom bezig.

Zelfs god maakt fouten!

[dusty]

Op woensdag 03 oktober 2001 16:02 schreef sjako het volgende:
leuk discussiepunt

Disclaimer: Mysql is GEEN Relationele database

[raptorix]

Op woensdag 03 oktober 2001 15:52 schreef HenkS het volgende:

[..]

zijn dat stopwoorden aan het worden hier op GOT? 'volgens mij' en 'ik denk dat' bij een antwoord zou het wel fijn zijn als mensen iets ZEKER weten. ik heb namelijk bij een optimalisatie niet iets aan een 'volgens mij'

verder geen persoonlijke kritiek maar een algemene, want het wordt wel ERG vaak gebruikt hiero

Als jij de persoon bent die aangestelt is om de db te optimaliseren ben jij de persoon die het hier zou moeten kunnen vertellen en niet de persoon die het hier moet komen vragen.

[Verwijderd]

Op woensdag 03 oktober 2001 16:04 schreef dusty het volgende:

[..]

Disclaimer: Mysql is GEEN Relationele database

doelde eigenlijk op cijfer/letter, maar ik begin er niet nog eens aan

[tomato]

Op woensdag 03 oktober 2001 16:07 schreef sjako het volgende:
doelde eigenlijk op cijfer/letter, maar ik begin er niet nog eens aan

* tomato was al aan het bladeren in de search

Maar ok, ik zal het /14 niet aan doen dat die thread weer iedere week omhooggetrapt wordt

[HenkS]

offtopic:
ik vind gewoon als je zelfvertrouwen hebt dat je 'ik denk dat' enzo niet moet gebruiken en hier je antwoord moet neerpleuren, is niet echt goed voor de vragensteller anders

weet niemand een goede handleiding voor db optimalisatie of hoe ee ndb snel te maken cq te houden


(mijn vraag betrefd trouwens sql-server, maar ja dit kan natuurlijk voor alle db's worden gebruikt)

[dusty]

Op woensdag 03 oktober 2001 16:07 schreef sjako het volgende:
doelde eigenlijk op cijfer/letter, maar ik begin er niet nog eens aan

Ook niet doen, ik geef toch niet op

[ACM]

Op woensdag 03 oktober 2001 16:30 schreef dusty het volgende:
Ook niet doen, ik geef toch niet op

Nou, wat is dan sneller?
Een enum(j,n) (en dan op j/n checken), een (small)int (en dan 0/1 checken of een bit-field (en dan dus ook op 0/1 checken)?

(* ACM gaat het es testen )

[HenkS]

denk t laatste


maar weet niemand een handleiding over dit alles?

[dusty]

Het laatste.

BTW: Je moet wel flink veel data verwerken

[3volution]

Op woensdag 03 oktober 2001 16:46 schreef ACM het volgende:

[..]

Nou, wat is dan sneller?
Een enum(j,n) (en dan op j/n checken), een (small)int (en dan 0/1 checken of een bit-field (en dan dus ook op 0/1 checken)?

(* ACM gaat het es testen )

Ik gebruik daarvoor altijd een int 0/1 (want een int kan in 1x door de processor verwerkt worden en een bit moet worden geconverteerd).

[tomato]

Op woensdag 03 oktober 2001 23:47 schreef Bertjooo het volgende:

[..]

Ik gebruik daarvoor altijd een int 0/1 (want een int kan in 1x door de processor verwerkt worden en een bit moet worden geconverteerd).

Eerst nadenken is natuurlijk altijd goed
Maar theorie is leuk, alleen is het vaak toch slim om ook even te kijken of het in de praktijk geldt (bij jouw (r)dbms).

[Verwijderd]

'k heb tijdje terug iets gelezen in de mysql docs dat mij deed kiezen voor enum, maar kweet het niet meer terug te vinden

[3volution]

Eerst nadenken is natuurlijk altijd goed
Maar theorie is leuk, alleen is het vaak toch slim om ook even te kijken of het in de praktijk geldt (bij jouw (r)dbms).
[/quote]

Natuurlijk, maar gezien de 'zeker-weten' discussie van hierboven had ik het anders nooit durven posten als het niet zou kloppen (met MSSQLServer dan).

[Verwijderd]

Op donderdag 04 oktober 2001 00:06 schreef woeitje het volgende:
'k heb tijdje terug iets gelezen in de mysql docs dat mij deed kiezen voor enum, maar kweet het niet meer terug te vinden

kep het gevonden...

http://www.mysql.com/doc/n/o/node_364.html

staat:

The size of an ENUM object is determined by the number of different enumeration values. One byte is used for enumerations with up to 255 possible values. Two bytes are used for enumerations with up to 65535 values. See section 6.2.3.3 The ENUM Type.

maarja dat is Mysql.... no clue wat andere databeesten doen

[tomato]

Eigenlijk vind ik dat je een kolomtype in eerste instantie kiest om een goed relationeel ontwerp te krijgen. Snelheid zou later pas moeten komen (of eigenlijk vanzelf).

Bij voorbeeld bij een keuze 'links' of 'rechts' is het mooier om voor een enum te gaan, dan 'weet' je database ook waar je het over hebt ipv een vertaalslag op een ander niveau toe te passen.

Aan/uit daarentegen vind ik redelijkerwijs wel als 0/1 te verdedigen.

[HenkS]

en nog steeds zoekt deze jongen een goed handleiding over indexen en optimalisatie


ps (wel leuke discussies)

ps2 ik heb totaal GEEN zin om vandaag te gaan werken