Optimerat sätt att lösa mitt problem?

Hejsan.

Jag håller på att bygga en site, där länkarna skall lägga sig i ordning efter hur många ggr de blivit klickade på, med den mest använda länken överst. Och detta skall vara unikt för den användaren som är inloggad på siten, hade jag tänkt.

Detta innebär att jag i databasen måste ha en tabell som håller koll på användaren, och hur många gånger han klickat på en specifik länk.

Så nu har jag då en liten fråga.

Är det smartare att bygga tabellen såhär:
UID
fldLänkID
fldClicks

och få en jäkla massa sådana inlägg, jag har ju för tillfället bara fem testanvändare, och fem länkar än så länge, vilket skulle innebära 25 rader i tabellen. Lägger jag till fler länkar blir de ju fler, och kommer det fler användare ökar ju det också rad antalet.

Eller, är det smartare med denna lösningen:

UID
fldLänk1
fldLänk1Clicks
fldLänk2
fldLänk2Clicks
fldLänk3
fldLänk3Clicks
fldLänk4
fldLänk4Clicks
fldLänk5
fldLänk5Clicks

Inget av fälten kommer ju någonsin att vara tomma, på sin höjd en nolla, och de kommer ju alltid att användas eftersom länkfältet med en nolla skall resultera i att den länken hamnar längst ned.

Lägger man till nya funktioner = nya länkar, så är det ju nästan enklare att rätta till det i alternativ två, genom att bara använda alter (kan inte exakt syntax men har ändrat rader förr så det kan inte varit överdrivet svårt ;) ) och lägga till två fält för varje rad, och fylla dem emd länkid´t och en nolla.

Med alternativ ett skulle man ju vara tvungen att köra en massa inserts (en för varje användare)

Så vilket är smartare? Både underhållsmässigt, och prestandamässigt.

Tacksam för svar.

MVH Patrik

Re: Optimerat sätt att lösa mitt problem?

Patrik81 skrev:

...Är det smartare att bygga tabellen såhär:
UID
fldLänkID
fldClicks

och få en jäkla massa sådana inlägg, jag har ju för tillfället bara fem testanvändare, och fem länkar än så länge, vilket skulle innebära 25 rader i tabellen. Lägger jag till fler länkar blir de ju fler, och kommer det fler användare ökar ju det också rad antalet.
...

Ja. :)

Dels är det så en relationsdatabas förväntas att byggas upp, dvs det är så man normalt sett får strukturen. För det som "hänger ihop" det är ju en viss användare med en viss länk och antalet gånger den tryckts på (av den användaren). Exempel: Om vi har länkarna A, B, C, D och E. Och användarna Ann, Bo och Carl så är
antalet gånger som Ann tryckt på A helt oberoende av antalet gånger hon tryckt på övriga fyra länkar. Och då ska det avspeglas i databasstrukturen.

Dels är problemet med att lägga in nya rader i en databas ett intet mot att lägga in fler kolumner. Nya rader påverkar inte det som redan står där, medan nya kolumner påverkar samtliga rader. De redan befintliga fick ju plötsligt fler kolumner att ha värden i.

Värst av allt: med den andra designen tvingas du skriva om samtliga SQL-frågor varje gång du lägger till en kolumn. För att plocka ut det du vill ur ovanstående skriver du (en gång för alla)

Select fldLänkID from Tabell where userID=<namn> order by fldClick DESC;

Jag förstår allt som sagts, och allt låter mycket vettigt, förutom möjligtvis den lilla punkten om att jag måste ändra mina sqlfrågor om jag väljer den andra designen. För använder jag mig utav den andra designen och bara hämtar hem den raden där användarID är detsamma som i tabellen, så kommer jag ju ändå att få sortera arrayen, men inte ändra frågan, så jag skulle vilja få en fördjupad insikt i hur du menade med det, men ditt svar var i alla andra avseenden fullt tillfredsställande så till den grad att jag är övertygad om att alt. 1 är rätta sättet att göra det på.

Tack så mycket :)

MVH Patrik

Patrik81 skrev:

Jag förstår allt som sagts, och allt låter mycket vettigt, förutom möjligtvis den lilla punkten om att jag måste ändra mina sqlfrågor om jag väljer den andra designen. För använder jag mig utav den andra designen och bara hämtar hem den raden där användarID är detsamma som i tabellen, så kommer jag ju ändå att få sortera arrayen, men inte ändra frågan, så jag skulle vilja få en fördjupad insikt i hur du menade med det, men ditt svar var i alla andra avseenden fullt tillfredsställande så till den grad att jag är övertygad om att alt. 1 är rätta sättet att göra det på....

Det är klart att om du hämtar hem hela raden och använder ditt applikationsprogram till att sortera länkarna i ordning så kan du ha EN SQL-sats. Men om du skulle försöka skriva en (eller flera) SQL-sats(er) för att försöka få ut resultatet sorterat från databasen direkt, så skulle frågan:
* Bli fruktansvärt komplex att skriva (om det ens skulle gå)
* Bero helt på ett exakt angivande av antalet kolumner.
Det var så jag tänkte.

Men, även om du plockade ut det från databasen genom att plocka ut hela raden, så skulle du ju i så fall tvingas sortera i efterhand och det bör, tycker jag, ta mera tid än att plocka ut dem sorterade från databasen med den föreslagna varianten.

Då är vi på samma våglängd. Tack :)

MVH Patrik