07. marts 2002 - 01:56Der er
12 kommentarer og 1 løsning
"genbrug" af et udtryk i SQL
Jeg er ved at lave en lille søgemaskine til en FAQ database, og man skal så kunne søge efter et spørgsmål ... min tabel ser således ud:
Question.QuestionID : AutoNumber [Pri.Nøgle] Question.QuestionText : Text [spørgsmålet] Question.Keywords : Text [kommesepareret liste over søgeord]
Jeg er nået frem til flg. SQL sætning, som i sig selv fungerer som den skal:
SELECT ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) AS [Relevance], [Question].[QuestionID], [Question].[QuestionText] FROM Question;
Ovenstående sætning giver mig så et nyt felt, [Relevance] der har værdien 0 hvis ingen af de to ord findes i [Keywords], 1 hvis en af dem findes, eller 2 hvis de begge findes. Det er mægtig fint.
Her er så problemet ... nu ville jeg gerne tilføje flg. til min sætning:
WHERE [Relevance]>0 ... for at filtrere irrelevante spørgsmål fra
og
ORDER BY [Relevance] DESC ... for at få de mest relevante spørgsmål først
Men det kan man ikke?! Access tror tilsyneladende bare at f.eks. ORDER BY [Relevance] refererer til en PARAMETER der hedder Relevance, og den kan den så ikke finde. Hvordan får jeg den til at forstå at det er mit FELT den skal sortere på, og ikke en eller anden parameter??
I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
SELECT ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) AS [Relevance], [Question].[QuestionID], [Question].[QuestionText] FROM Question WHERE ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) > 0 ORDER BY ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0)));
Blot en lille rettelse Niels (som jeg selvf. ikke skal have point for):
SELECT ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) AS [Relevance], [Question].[QuestionID], [Question].[QuestionText] FROM Question WHERE ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) > 0 ORDER BY ((IIf([Keywords] Like '*hardware*',1,0))+(IIf([Keywords] Like '*enable*',1,0))) DESC;
Rettelsen var bare det sidste ord DESC - da det jo var det, som Mindplay bad om :o)
Det var også det SQL generator'en kom frem til i Access, og det var det jeg helst ville undgå - for det første må det være ekstremt ineffektivt at lade fortolkeren evaluere hele udtrykket op til 3 gange, for det andet får jeg problemer med længden ... udtrykket bliver genereret i et script, nogengange med mange flere end 2 nøgleord som i eksemplet her...
Der må da være en måde at undgå at parse hele udtrykket 3 gange på? Kan man ikke f.eks. starte med at lave et "view" eller sådan noget? Jeg bruger ADO - kan man evt. lave SELECT'en som en procedure først, og så teste or sortere på [Relevance] feltet bagefter?
MindPlay -> Der er ikke noget sparet, hverken i hastighed eller resourser, ved at splitte din forspørgsel op i flere - tværtimod er den sværere at vedligeholde.
Thomas -> 'DESC' - den glemte jeg, Klokken var ved at være mange ;o)
Niels-> Har du noget dokumentation for at du ikke vinder noget hastighed ved at splitte forespørgslerne op i flere? Eller er det bare din erfaring/fornemmelse?
Jeg læste faktisk engang et whitepaper fra Microsoft, hvor de skrev at man med fordel kunne opsplitte komplekse forespørgsler i flere.
mht vedligeholdelse, så kan der da også være fordele ved at lave en basis-forespørgsel hvor man har lavet de beregnede og sammensatte felter og så derfra bygge videre. Især hvis du skal bruge de samme sammensatte felter i flere forespørgsler.
Du burde nok i stedet for et kommasepareret felt med søgetekster i stedet lave en tabel mere i stil med: Keywords ID autonummer QuestionId Keyword Du kan så joine op mod den tabel, lave en gruppering og en count og det skulle kunne gøre dit udtryk noget simplere.
Multivalue-felter bryder med normaliseringen og det kan der være gode grunde til nogle gange men forespørgsler er almindeligvis noget lettere at have med at gøre hvis man overholder sine normalformer.
Thomas -> Jeg har nu ingen dokumentation, men en fornemmelse af at 'flaskehalsen' ligger i netværkstrafiken, altså hvor stort recordsettet er. Om SQL sætningen er stor eller lille betyder i den forb. ikke så meget. Under alle omstændigheder er det Access, der skal udføre beregningerne i 'iif()' functionen samt SQL operatoren 'LIKE', det foregår ikke i scribet.
Jeg har engang læst at foruddefinerede forespørgsler er hurtigere end forespørgsler, der genereres i div. subrutiner og scribts, fordi Access har verificeret SQL syntaksen én gang, hvorimod nye SQL sætninger skal kontroleres hver gang, men jeg har aldrig kunnet måle nogen forskel i hastighed.
haha, ja Terry haler godt ind på mig. De kan ikke have særlig meget at lave ovre hos Lego, siden har har så meget tid ;o)
Men jeg kan fortælle at jeg i ca ½ år ikke har kunnet skrive svar uden at skulle skrive/indsætte teskten 10-50 gange før den blev accepteret og vist på eksperten. Det betyder for det første, at jeg ikke har gidet svare særlig meget i det halve år (osær de sidste 2-3 måneder har det været slemt), for det andet betyder det at det næsten var umuligt at NÅ at svare inden Terry eller en anden havde svaret.
Men det er slut nu! Af en eller anden grund, så har jeg kunne poste mine svar i første forsøg den sidste uges tid :o)))
Nu er mit eneste problem bare at jeg har pokkers travlt og tit sidder ude hos kunder, så jeg slet ikke har mulighed for at svare :o(
Det kunne være at man skulle mail-bombe Terry eller lign for at sinke ham lidt, hehe :o)
Pjat til side...Terry må da gerne overhale mig (og det gør han jo ganske givet snart)
Hvad med dig selv - du må da også snart dukke op på listen! Eller hvad?
Jeg tror godt jeg kan måle mig med jer ÆGTE eksperter mht. viden om Access. MEN jeg mangler altså lidt i hurtighed, svartider på under 1 min. kan jeg ikke være med. Desuden beundrer jeg jeres evne til at forstå spørgsmålene - de er tit lidt tvetydige
Så skal du oprette poster i 'Relevans' for hvert spørgsmål med tilhørende Keywords. Senere når du søger i databasen Counter du antalet af keywordID'er i tabelen relevans og får tihørende QuestionID.
hm, det har vist stået åbent lidt længe .. havde jeg glemt alt om. Jeg er i øvrigt for længst gået over til Apache/PHP/MySQL i stedet for, det gir knapt så meget "knas" ;)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
