/ 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
rank algoritme - best bet search
Fra : jetpoet@yahoo.com


Dato : 06-06-03 20:24

Hej med jer,

jeg vil gerne vide om nogle af jer kender til en ranking algoritme. Jeg har
planer om at implementere følgende i min database.

Giv et element en karakter fra -5 til +5 og så skal systemet give nogle
forslag til andre elementer, der kunne være interessante baseret på denne
brugers karakter og andre brugeres karakterer. Det kan gøres på to måder,
enten ved at siger: "folk, der kunne lide dette element kunne også lide
disse elementer" og så regne de 5 "best bets" ud for det element der vises.
Lidt ligesom på Amazon, eller også ved at sige, "jeg kan lide det her, andre
folk med lignende interesser kan lide det her". Den anden model er lidt
sværere at implementere tror jeg umiddlebart. Det kræver i hvert fald mere
af algoritmen da der er mange elementer at tage stilling til i stedet for
kun et element.

Jeg har forestillet mig at jeg ville lave en tabel, der så sådan her ud:

RANK
-------------------
USER_ID
ELEMENT_ID
RANK

Men så bliver det svært, for så skal man igang med nogle slemme queries. Er
der nogen, der kender til algoritmer, der kan løse det problem jeg her
beskriver. Skal man til at lave noget data warehousing hvor man med
mellemrum regner nogle cubes ud eller hvad skal man til? Jeg har overvejet
nogle forskellige stored procedures der kan hente nogle sorterede lister ud,
som kunne danne basis for beregningen af den rank men har ikke helt fundet
ud af den bedste metode endnu.

Med venlig hilsen og håb om insigtsfulde svar...

 
 
Nikolaj Hansen (08-06-2003)
Kommentar
Fra : Nikolaj Hansen


Dato : 08-06-03 23:27

Jeg har også kigget lidt på ranking systemer, og er kommet frem til at de,
efter min mening. mest er af akademisk værdi.

Grunden hertil er, som på eks amazon, at selve ranking systemet har en
gennemgående indflydelse på sig selv. Dvs. hvis du anbefaler en søgning /
element, vil der være flere og flere, der kigger på det element. Derved vil
der igen være flere og flere der ser det osv osv.

Derfor er man nødt til at se bort fra hits i statistikken til en ranking
database, der kommer fra ranking systemet selv. og i en web gui (hvis det er
det du laver) kan det godt være ret så tricky at finde ud af, hvad der skal
med i statistikken og ikke.



Christian Estrup (15-06-2003)
Kommentar
Fra : Christian Estrup


Dato : 15-06-03 14:45

Slemme og slemme - én model kunne være at lave en 'hitliste' ud fra folks
karakterer til andre elementer, ganget med deres karakter til det aktuelle.
Herved vil karakterer fra de, der bedst kan lidt det aktuelle, tælle mere.

Altså noget i retning af:

SELECT R1.ElementID
FROM Rank R1 INNER JOIN Rank R2 ON R1.UserID = R2.User.ID AND R1.ElementID
<> R2.ElementID AND R2.ElementID = [AktueltElement]
ORDER BY R1.Rank * R2.Rank DESC


- Chr

<jetpoet@yahoo.com> wrote in message
news:9d093ada.0306061124.45b6cb97@posting.google.com...
> Hej med jer,
>
> jeg vil gerne vide om nogle af jer kender til en ranking algoritme. Jeg
har
> planer om at implementere følgende i min database.
>
> Giv et element en karakter fra -5 til +5 og så skal systemet give nogle
> forslag til andre elementer, der kunne være interessante baseret på denne
> brugers karakter og andre brugeres karakterer. Det kan gøres på to måder,
> enten ved at siger: "folk, der kunne lide dette element kunne også lide
> disse elementer" og så regne de 5 "best bets" ud for det element der
vises.
> Lidt ligesom på Amazon, eller også ved at sige, "jeg kan lide det her,
andre
> folk med lignende interesser kan lide det her". Den anden model er lidt
> sværere at implementere tror jeg umiddlebart. Det kræver i hvert fald mere
> af algoritmen da der er mange elementer at tage stilling til i stedet for
> kun et element.
>
> Jeg har forestillet mig at jeg ville lave en tabel, der så sådan her ud:
>
> RANK
> -------------------
> USER_ID
> ELEMENT_ID
> RANK
>
> Men så bliver det svært, for så skal man igang med nogle slemme queries.
Er
> der nogen, der kender til algoritmer, der kan løse det problem jeg her
> beskriver. Skal man til at lave noget data warehousing hvor man med
> mellemrum regner nogle cubes ud eller hvad skal man til? Jeg har overvejet
> nogle forskellige stored procedures der kan hente nogle sorterede lister
ud,
> som kunne danne basis for beregningen af den rank men har ikke helt fundet
> ud af den bedste metode endnu.
>
> Med venlig hilsen og håb om insigtsfulde svar...



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

Månedens bedste
Årets bedste
Sidste års bedste