Søgning - nyeste ligger sidst

I en søgning i din database, vil vel altid kræve at man søger den fuldstændig igennem, ellers kan man vel aldrig være sikker på at alle poster blev fundet?

--
pacroon

Jeg har forskellige begrænsningsmuligheder i stil med LIMIT.

Det er korrekt - men jeg er ikke så meget inde i søgealgortimer at jeg kan gennemskue om den stadig kører hele listen igennem.

Måske kan det være, at hvis du vælger ORDER BY id DESC, eller noget i den stil, at den starter nedefra.

Det kunne et gæt være..

ORDER BY, LIMIT og index på feltet burde gøre det

Hej Arne
Så vidt jeg har forstået medfører et index at db opretter en ekstra tabel hvor kun indexværdierne indgår så der læses færre data pr. post når der søges, og når en korrekt post i denne tabel findes anvendes indexværdierne som henvisning til den post i den tabel hvor de hører hjemme.
Findes der metoder til løbende at sortere disse tabeller så alle poster med indexværdi 'a' i kolonnen 'status' altid ligger øverst og tilsvarende 'd' altid ligger nederst (så kan man jo søge med WHILE), og kan man få db til at starte søgning bagfra i tabellen?

Mvh CONCAT(fornavn,' ',efternavn) LIKE '%an he%'

implementeringen af index er lidt forskellig

men logisk set kan du betragte værdierne i indexet som sorteret
så det er meget hurtigt at finde en bestemt værdi og meget nemt at
finde alle værdier både i normal rækkefølge og i omvendt rækkefølge

[teknisk set er det normalt en træ struktur]

du kan bruge træ baserede index til LIKE 'xxx%' men ikke til LIKE '%xxx%' - den
sidste kræver altid en fuld table scan

Det skal måske lige nævnes at jeg anvender det grafiske værktøj MySQL Adm.
Hvad er default for index, og hvis man anvender BTREE-struktur nivelerer MySQL så træet løbende, el. skal det defineres manuelt til f.eks at ske en gang i døgenet? Hvis man anvender Hashing så skal man vel have foruddefineret en størrelse på tabellen?

BTREE

som jeg husker det så er et B-træ altid balanceret i modsætning til et normalt ISAM-træ

HASH index kan kun bruges til at slå enkelt værdier op med - det duer ikke
til andre anvendelser

men et hurtigt kig i MySQL docs afslører at index på on disk tabeller altid
er BTREE - det er kun til in memory tabeller at man har valget mellem BTREE
og HASH

så valget er nemt

og der ser ikke ud til at være nogle konfigurations muligheder for de index
(i modsætning til så mange andre databaser)

Et sidste lille spørgsmål.
Min viden om sortering i tabeller er på det teoretiske plan. Jeg har ikke tidligere skulle programmere db i større sammenhæng. Jeg valgte at anvende MyISAM tabeller fordi jeg læste at det var hurtigst ved søgning - og min db skal anvendes i sammenhæng med en større hjemmeside.
Jeg var ikke klar over at der også findes ISAM-træer. Hvis det ikke tager dig alt for lang tid og hvis det kan siges kort så - hvad er det?
Under alle omstændigheder acsepterer jeg ikke en 'kommentar' - kun 'svar' er anvendeligt.
Mange tak for hjælpen - Christian

MyISAM tabeller er hurtiger til queries og hurtigere end stort set alle
andre databaser fordi de ikke bruger transaktioner

en normal indeks sekventiel fil gror altid ned ad - ligesom når du indsætter
i et binært træ, hvorimod B-træer laver det specielle page split som medvirker
til at holde træet balanceret

teknisk set er B-træ vel et special tilfælde af et indeks sekventielt træ
og det man bruger idag (MyISAM bruger også B-træer)

og svar

Mange tak skal du have - en stor sten fra mine skuldre.
Mvh Christian