webForumDet fria alternativet

Ny tabell för varje user eller en array?

5 svar · 198 visningar · startad av Zaphod

ZaphodMedlem sedan maj 2000107 inlägg
#1

Hehe, den som fattade något utav den topicen får ett extraliv utav mig. ;)

Iaf, här har ni något att bita i.
Jag skall göra ett system där man kan lägga in siter och sedan rösta på dem (lite som på www.snyggt.com).
Man måste registrera sig innan man får rösta för att vissa element inte skall rösta flera gånger. Så därför vill jag ha en funktion som registrerar på vilka siter (ID) som användaren har röstat på, och om han/hon har röstat innan så kan de bara uppdatera sitt betyg på siten. Detta för att det inte går att hålla bra koll på cookies. Frågan är bara hur jag skall lösa detta, och om det ens är värt kodningen?

Jag har två idéer på hur jag kan göra just nu. Antingen så tar jag och gör en ny tabell för varje användare som reggar (genom T-SQL) det har ju sina fördelar i att det är lätt att söka, ändra och uppdatera. Men jag kommer att få 1000 miljarders jälva tabeller överallt. Vilket ju känns ganska otympligt

Den andra är att emulera arrays, arrays verkar inte finnas i SQL Server (utav förklarliga skäl. Databaser är ju som anvancerade arrays ju!), genom att ta och ha ett varchar(fettomångasiffror)fält där man lägger till ID:t efter varje gång användaren har röstat på någon ny site. Så efter ett tag skulle det kanske se ut såhär: 0001000200420003 = Site med ID 1, site med ID 2, site med ID 42, site med ID 3 etc.

Sedan när man skall kolla detta så gör man en temporär tabell och loopar igenom denna varchar:en med SUBSTRING och tar ut alla värden och konverterar dem till int (och tar därmed bort onödiga nollor) varpå man sätter in dem i den temporära tabellen, sedan tar man och söker och ser ifall man hittar något som motsvarar id:t som skickades in i SP:n, droppar tabellen och ger resultat.

Sammanfattning: Vilken metod skall jag använda? Vilken metod tar minst på SQL databasen? Det säger ju sig självt att skapa en tabell för varje användare tar massa kraft och plats. Men å andra sidan så behöver man bara göra det en gång. Det som jag inte gillar med det är att man får hur många tabeller som helst som bara ligger å skräpar.

Den andra kan kännas som overkill i programmeringsväg kanske, plus att det kanske tar en stund att skapa alla dessa temporära tabeller och söka. Det bra med denna metoden är ju att det blir så mkt "renare" och snyggare. Kan ju vara jobbigt ifall jag kommer över 1000 siter gränsen dock. Då måste jag lägga till en 0:a på varje tal i varchar:en :(

DILEMMA!
Ett snabbt svar vore mkt uppskattat!

------------------
/Magnus aka Zaphod
www.designmodule.com

[EDIT: Dags att lära sig lite grammatik och meningskonstruktion kanske, magnus?]

[Redigerat av Zaphod den 17 apr 2001]

DustyMedlem sedan juli 2000103 inlägg
#2

Vad sägs om att bygga en normaliserad relationsdatabas av det hela? Ung. såhär:

Användare
ID
Namn

Sajter
ID
Namn
URL

Röstningar
ID
SajtID
AnvandarID
Betyg

Ganska snabbt svarat iaf. :e

På detta sätt slipper du allt vad mongomassa tabeller heter, och du sparar all data i minsta möjliga form. Det där med sammansatta fält är en dålig idé. När du sedan ska plocka ut datan, eller kolla om ngn redan röstat är det bara att trixa lite med joins.

Fast jag kanske har missförstått vad du vill uppnå totalt?

------------------
That you're paranoid doesn't mean you're not being monitored...
Monitora

[Redigerat av Dusty den 17 apr 2001]

ZaphodMedlem sedan maj 2000107 inlägg
#3

Jodå, det var snabbt. Tack så mkt!
Det kanske du har rätt i. Jag hatar när jag krånglar till det i huvudet bara för att jag är mitt uppe i något.

Enda skulle väl vara att det blir nog en ganska fet tabell efter ett tag. Men det borde väl väga upp att göra massa nya tabeller hela tiden tycker jag nog?

"Den lättaste lösningen är oftast den bästa" - mig själv. Precis nu. :e

------------------
/Magnus aka Zaphod
www.designmodule.com

DustyMedlem sedan juli 2000103 inlägg
#4

Användare, Sajter och Röstningar är alltså tre olika tabeller. Och hur stor varje tabell är spelar ingen roll. Naturligtvis är det skillnad på 1 000 000 poster och 10 poster, men har du bara rätt index bör det fungera ändå.

Tabeller ska vara stora för 17! :e

------------------
That you're paranoid doesn't mean you're not being monitored...
Monitora

ZaphodMedlem sedan maj 2000107 inlägg
#5

Jo, jag fattar. :)
Jag har gjort så nu att jag har en tabell som bara skall lista vad folk har röstat på. Så har jag en row som bestämmer vilken typ utav röst det är. För jag kommer att ha flera olika röstningssystem. Annars så var databasen uppbyggd på liknande sätt som du har visat innan. Där members tabellen är själva navet.

Hade faktiskt tänkt att göra som du sa från början. Men så tyckte jag att det skulle bli en bautastor tabell (vilket det ju blir iof, e ju inte bra när man skall söka igenom den ofta) och att det måste gå att lösa på ett snabbare sätt. Så jag började spåna på andra lösningar och mitt i allting så glömde jag utgångspunkten. Alltid lika jobbigt när det händer och man inser hur jäkla borta man har varit hela tiden. :)

Men nu är jag på rätt väg igen. Danke. Bra när någon tar ner en på jorden igen när man är uppe å flummar i det blå :e

------------------
/Magnus aka Zaphod
www.designmodule.com

DustyMedlem sedan juli 2000103 inlägg
#6

Nej, man ska inte tänka för mkt, då blir det bara fel. ;) :e

Tror att det finns ngn gammal tråd om antal poster vs. sökhastighet. Hittar den inte dock. Men indexerar du bara alla fält du ställer vilkor så är det antagligen rätt lungt.

Själv har jag en Access-tabell med 13000 poster, ur vilken jag plockar saker mha söksatser som innehåller 5 nestade joins. Segar inte märkvärt. :)

------------------
That you're paranoid doesn't mean you're not being monitored...
Monitora

130 ms totalt · 3 externa anrop · v20260731065814-full.30151723
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
127 ms — hämta tråd, inlägg och bilagor (db)