---

Jeg har en tabel med omtrent 700.000 rækker, hvor hvert opslag i tabellen
kræver et komplet tablescan. Det har en ufavorabel indvirkning på
opslagstiden, som i mit nuværende setup udgør godt 3-4 sekunder.

Jeg har en formodning om at tilgangstiden og båndbredden til RAM i det
væsentlige er ufatteligt meget hurtigere end til harddsik, hvorfor det kunne
være en fordel at placere mine data her.

Har nogen erfaringer med et sådant setup -- helst med en opensource database
som postgresql eller mysql? Er der nogen alvorlige faldgruber, man bør være
opmærksom på.

/A

---

Anders Johannsen wrote:
>
> [...] hvert opslag i tabellen kræver et komplet tablescan. [...]

Gisp! Hvad er dog det for en skrækkelig sql, der gør at du ikke kan
benytte et indeks? og hvilket database-produkt bruger du?

--
Lauritz

---

> Gisp! Hvad er dog det for en skrækkelig sql, der gør at du ikke kan
> benytte et indeks? og hvilket database-produkt bruger du?

Databasen indeholder en liste med oplysninger om en del filer samt deres
oprindelse. Strukturen er løseligt som nedenfor:

tFile
iSourceId
varPath
varName
[...]

Den primære nøgle er en kombination af (iSourceId, varPath, varName). Jeg
har prøvet både med og uden index på varName.

En typisk forespørgsel vil være "SELECT iSourceId, varPath, varName FROM
tFile WHERE varName LIKE '%forespørgsel%'"

/A

---

"Anders Johannsen" <anders@ignition.dk> wrote in message
news:9c8n80$ap0$1@news.inet.tele.dk...
>
> En typisk forespørgsel vil være "SELECT iSourceId, varPath, varName FROM
> tFile WHERE varName LIKE '%forespørgsel%'"
>
Det er din like der giver en tablescan uanset hvad du bruger af indeks
Specielt % i starten er "godt" - desværre

Hvilket databaseprodukt bruger du pt?
Undersøg om du kan lave noget Full Text Index - lidt i stil med man kan på
MSSQL

mvh/Peter Lykkegaard

---

Anders,

Hvad med at lave en ikke sammensat primærnøgle? Fx. blot [ID]. Jeps, der er
ikke optimal normalisering, men mon ikke performance ¨ville blive forøget
aligevel...
--
Frederik Jensen, Judex

"Anders Johannsen" <anders@ignition.dk> wrote in message
news:9c8n80$ap0$1@news.inet.tele.dk...
> > Gisp! Hvad er dog det for en skrækkelig sql, der gør at du ikke kan
> > benytte et indeks? og hvilket database-produkt bruger du?
>
> Databasen indeholder en liste med oplysninger om en del filer samt deres
> oprindelse. Strukturen er løseligt som nedenfor:
>
> tFile
> iSourceId
> varPath
> varName
> [...]
>
> Den primære nøgle er en kombination af (iSourceId, varPath, varName). Jeg
> har prøvet både med og uden index på varName.
>
> En typisk forespørgsel vil være "SELECT iSourceId, varPath, varName FROM
> tFile WHERE varName LIKE '%forespørgsel%'"
>
> /A
>
>

---

> Hvad med at lave en ikke sammensat primærnøgle? Fx. blot [ID]. Jeps, der
> er ikke optimal normalisering, men mon ikke performance ¨ville blive
> forøget aligevel...

Det giver desværre nogen problemer i forbindelse med opdatering af
databasen.

/A

---

Frederik Jensen wrote:
>
> Anders,
>
> Hvad med at lave en ikke sammensat primærnøgle? Fx. blot [ID]. Jeps, der er
> ikke optimal normalisering, men mon ikke performance ¨ville blive forøget
> aligevel...

Hvad mener du med at det ikke er optimal normalisering? Det påvirker
overhovedet ikke normaliseringen.

VH Kristian

PS. Almindelig usenet standard er at placere svaret *efter* det man
svarer på. Samt at slette overflødige dele af det oprindelige indlæg.

--
Kristian Damm Jensen | Feed the hungry. Go to
kristian-damm.jensen@capgemini.dk | http://www.thehungersite.com

---

"Kristian Damm Jensen" <kristian-Damm.Jensen@REMOVEcapgemini.dk> wrote in
message news:3AE97435.9CD4002E@REMOVEcapgemini.dk...
> Frederik Jensen wrote:
> >
> > Anders,
> >
> > Hvad med at lave en ikke sammensat primærnøgle? Fx. blot [ID]. Jeps, der
er
> > ikke optimal normalisering, men mon ikke performance ¨ville blive
forøget
> > aligevel...
>
> Hvad mener du med at det ikke er optimal normalisering? Det påvirker
> overhovedet ikke normaliseringen.

Kristian,

det jeg mener er foelgende: loebenummeret [ID] er redundant information da
den sammensatte noegle udgoer en unik vaerdi. Det er brud paa 2.normalform:
attributter skal kun vaere afhaengig af primaernoeglen.

Well, principielt burde performance vaere daarligere hvis der soeges paa en
sammensatnoegle frem for blot en ikke sammensat.

--
Frederik Jensen, Judex

---

"Frederik Jensen" <fj@judex.dk> wrote in message
news:9c9847$238i$1@news.cybercity.dk...
> Anders,
>
> Hvad med at lave en ikke sammensat primærnøgle? Fx. blot [ID]. Jeps, der
er
> ikke optimal normalisering, men mon ikke performance ¨ville blive forøget
> aligevel...

1) Din citeringsteknik kunne være bedre
2) Index har ikke dærligt meget med normalisering at gøre
2) Reducering af felter i index giver forbedring af performance ved
opdatering/indsætning af data, sjældent ved læsning af data - imho

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> wrote in message
news:jp7H6.6$Dp6.748@news.get2net.dk...
> 1) Din citeringsteknik kunne være bedre

Peter,
min citeringsteknik er vel et andet emne...
Tager gerne mod kritik, men fortael mig da hvordan jeg kunne goere det
bedre.

mvh
Frederik Jensen

---

"Frederik Jensen" <fj@judex.dk> wrote in message
news:9d6396$2n6e$1@news.cybercity.dk...
>
> "Peter Lykkegaard" <polonline@hot.mail.com> wrote in message
> news:jp7H6.6$Dp6.748@news.get2net.dk...
> > 1) Din citeringsteknik kunne være bedre
>
> Peter,
> min citeringsteknik er vel et andet emne...
Er vel så

> Tager gerne mod kritik, men fortael mig da hvordan jeg kunne goere det
> bedre.
>
Sorry, jeg glemte at give et lille link, vi er jo kun mennesker
http://www.usenet.dk/netikette/quote.html

mvh/Peter Lykkegaard