/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Concorde C5 : Hvad er hurtigst - IF eller ~
Fra : Kim Noer


Dato : 21-10-02 14:28

Davsen der..

Jeg prøver at baske noget kode sammen, der gerne skulle kunne 'skalere'
pænt med antal poster. Jeg har nu et nyt felt som skal tjekkes for hver
linie jeg laver en SEARCH på. Jeg må ikke oprettet et index der har
dette felt, da det vil betyde en langsommere INSERT. Min løkke ser
således ud (begge versioner) :

Uden IF:

SEARCH OrdKart USING NumTraIdx ORDER By Oprettet WHERE Transaktion == 0
AND Felt == "GNU"

Med IF:

SEARCH OrdKart USING NumTraIdx ORDER By Oprettet WHERE Transaktion == 0
IF Felt == "GNU" THEN
PRINT "Bøf"
....

Fordelen ved 'uden IF' er at jeg der ikke risikere at skulle igennem
4999 poster, før jeg rammer en Felt == "GNU" (hvis vi siger nummer 5000
er en med Felt == "GNU". Spørgsmålet er om Concorden håndterer dette
felt uden for index hurtigere end ved en efterfølgende IF. Hvad siger I?
Umiddelbart afhænger det 100% af dataerne, men hvornår holder det ikke
:).

Håber I forstår hvad jeg prøver at sige :).
--
If 0 thinks it looks like O, then 0 got a problem right?


 
 
Erik Hansen (21-10-2002)
Kommentar
Fra : Erik Hansen


Dato : 21-10-02 21:14

On Mon, 21 Oct 2002 15:28:19 +0200, "Kim Noer" <kn@nospam.dk> wrote:

>Jeg prøver at baske noget kode sammen, der gerne skulle kunne 'skalere'
>pænt med antal poster. Jeg har nu et nyt felt som skal tjekkes for hver
>linie jeg laver en SEARCH på. Jeg må ikke oprettet et index der har
>dette felt, da det vil betyde en langsommere INSERT. Min løkke ser
>således ud (begge versioner) :

Hvis hastigheden er så afgørende så vil jeg alligevel oprette et
index, det er meget lidt ekstra ekstra index sænker din hastighed, jeg
tror ikke engang du vil kunne mærke det. Det vil jo kun være et lille
index, som består af Nummer, Transaktion, GNU(felt).

>Uden IF:
>
>SEARCH OrdKart USING NumTraIdx ORDER By Oprettet WHERE Transaktion == 0
>AND Felt == "GNU"
>
>Med IF:
>
>SEARCH OrdKart USING NumTraIdx ORDER By Oprettet WHERE Transaktion == 0
> IF Felt == "GNU" THEN
> PRINT "Bøf"
>...

Jeg tror de vil være lige hurtige, det er vil være meget lidt forskel,
for det er stadig den samme mængde data som SEARCH skal løbe igennem.
Måske vil sætningne uden IF være en smule hurtigere, da den ikke skal
lave en IF som også tage tid.

>Fordelen ved 'uden IF' er at jeg der ikke risikere at skulle igennem
>4999 poster, før jeg rammer en Felt == "GNU" (hvis vi siger nummer 5000
>er en med Felt == "GNU". Spørgsmålet er om Concorden håndterer dette
>felt uden for index hurtigere end ved en efterfølgende IF. Hvad siger I?
>Umiddelbart afhænger det 100% af dataerne, men hvornår holder det ikke
>:).

Uden at kende jeres måde at bruge C5 på, så syntes jeg det lyder
voldsomt at have 5000 åbne ordre i jeres ordrekartotek. Husk på at
ordre som er faktureret har fået et transaktion nummer og der vil
derfor ikke indgå i den søgelykke.


--
....::Hilsen Erik

Kim Noer (28-10-2002)
Kommentar
Fra : Kim Noer


Dato : 28-10-02 13:36

Erik Hansen wrote:

> Hvis hastigheden er så afgørende så vil jeg alligevel oprette et
> index, det er meget lidt ekstra ekstra index sænker din hastighed, jeg
> tror ikke engang du vil kunne mærke det. Det vil jo kun være et lille
> index, som består af Nummer, Transaktion, GNU(felt).

Det blev så også løsningen, at sætte et ekstra index på. Problemet er så
bare nu, at GNU skal opdateres, og GNU indgår i indexet, og ved en
opdatering bliver posten flyttet 'nedad', hvilket betyder at jeg kommer
forbi samme poster to gange i en SEARCH.

--
If 0 thinks it looks like O, then 0 got a problem right?


Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408926
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste