Jag har ett forum som jag meckat med i många år, och som förfinas lite allteftersom.
Ett önskemål dök upp för typ 1 år sen att man ville att forumpost/tråd länkar skulle förbli "besökta" även om man tittat på dem på jobbets dator och sen kom hem till sin privata.
Har löst det med att lagra små sträng krumelurer på användarnivå i DB i ett fält på max 2000 varchar. Sen när jag ritar ut länken så kollar jag om användaren har denna krumelur eller inte o sätter olika css klasser.
Tyvärr så räcker det inte så långt utan efter några dagar/veckor så blir de besökta länkarnas krumelurer utknuffade ur DB-fältet och på så vis "obesökta" igen.
Det känns som om detta borde gjorts många gången förr och dessutom många gånger smartare än min ganska yxiga lösning....
Så frågan är alltså, är det någon här som känner igen problemet och kanske sitter inne med lite smarta tips?
En helt vansinnig lösning som går ut på att leka med 2-potenser där varje sida får ett tal i en 2-potensserie. Sedan summerar men ihop sidornas tal och gör om till ett decimaltal som sedan lagras i DB. Talet anger då explicit vilka sidor som visats. Det kan kanske bli ett ganska stort tal, men det borde gå :)
Sida nr1 har värdet 1
Sida nr2 har värdet 10
Sida nr3 har värdet 100
Har man besökt sida 1 och 2 har man värdet 11 (= 3 decimalt som lagras).
Har man besökt sida 1 och 3 har man värdet 101 (= 5)
Fast 52 sidor ger ett tal på 2.2e15 så det kanske är för stort för en databas? Men visst vore det skoj att implementera? :p
Hehe det låter intressant men jag tror inte det går.....det är ca 5000 poster i online DB + 50 000 i den arkiverade DB
Däremot kanske man kunde slå ihop alla krumelurer till en sträng (såsom det är i DB fältet just nu) och att man hashar strängen till ett värde? men MD5 går ju inte att reverse-a upp igen, finns det nåt liknande som man kan köra baklänges kanske?
Tilläggas bör kanske att krumelurerna som sparas också är tidsstämplar för varje post
Jag måste var korkad men jag ser inte problemet ;)
Om varje post har ett ID och varje användare måste vara inloggad för at information skall kunna sparas, så spara du bara ner postens ID och användarens ID i en tabell och oberoend på vilken dator man loggar in på så kan man alltid kontrollera om denna användare har sett denna post.
Nja lite kanske, jag måste spara klockslags-tillägget oxå, för annars blir inte editerade poster "obesökta".
Själva problemet är att jag använder ett varchar(2000) för att spara dessa poster, och att det inte räcker till.
Visst kan man skapa en tabell och koppla till, men jag hade tänkt försöka undvika detta (det blir ytterligare en db fråga + att jag är på gränsen redan för mina 10mb SQL DB på webhotellet...)
Men om du editerar en post, kan du då inte samtidigt bara plocka bort trådens id från tabellen där du har dina sparade besökta trådar? Men visst, det blir ju en stor tabell kanske. En fuskis skulle väl vara att man kanske släpper trådar som är äldre än något år.
Visst kan man skapa en tabell och koppla till, men jag hade tänkt försöka undvika detta (det blir ytterligare en db fråga + att jag är på gränsen redan för mina 10mb SQL DB på webhotellet...)
Helt beroende på vad du har för typer på dina id:en så spara du faktiskt plats på disk genom att använda dig av en ny kolumn.
Jag hade den diskutionen på detta forum för något år tillbaka sedan, där vi diskuterade storleken på sparade poster.
Här är en lite fingervisning. En Integer tar upp 2 bytes (tror jag det är) och ett tecken i din varchar sträng tar upp 1 byte, så ett ID med nummer 32000 tar upp 2 byte som en integer och 5 byte som en sträng.
Nu brukar inte en Integer räcka som längd på nycklen utan man brukar få använda sig av long som tar upp 4 bytes, men med de så klara du dig riktigt långt också, några miljarder typ... Så om du tänker på uttrymmet så kan det löna sig att byta till en ny tabell. Dessutom så lär ju dina 10 MB inte räcka i alla evighet och du måste köra mer uttryme för eller senare, och en korrekt databas design är en vinnare i längden...
Nja lite kanske, jag måste spara klockslags-tillägget oxå, för annars blir inte editerade poster "obesökta".
Nej du måste inte spara klockslaget, du kan ju ta bort posten från databasen om det inte är så att du använder klockslaget till något annant än just veta om man har nya inlägg eller ej. Dessutom spara det ju uttrymme för dig :)
oooppss såg att inspiro hade föreslagit samma sak... man kanske skall läsa alla inlägg innan man börjar att svara :)
- M
Jag tror det blir som de flesta verkar tycka, en extra tabell med bara integers..
Jag undrar dock hur mycket en rad i en tabell tar i utrymme, kanske ingen alls??
Säg att en användare har kikat på 1300 poster senaste året, det blir alltså 1300 rader i tabellen. Så om det är 2 kolumner int userId + postId, så är det typ 4 byte per rad, är den tabellen verkligen bara 5200 bytes stor? finns inget overhead?
Sen är vi ju cirka 50 aktiva användare, så det blir ju en del rader... jag menar det gäller ju att läsa in allt en gång för alla och sedan loopa igenom trådarna o sätta rätt css-klasser och inte göra en db fråga för varje post DÅ blir det långsamt :D
Angående DB storlek så har jag lyckats hålla den på 10 mb en längre tid nu, har ett arkiv som jag dumpar över dagligen poster till som är en vanlig access skrutt db, som funkar alldeles utmärkt.
Jag tror det blir som de flesta verkar tycka, en extra tabell med bara integers..
Tänk på att med integer kan du bara lagra tal upp till 65000, så om du har post id eller användare id som är större än det så kan du inte använda integers utan måste upp till bigint/long...
frequez skrev:
Säg att en användare har kikat på 1300 poster senaste året, det blir alltså 1300 rader i tabellen. Så om det är 2 kolumner int userId + postId, så är det typ 4 byte per rad, är den tabellen verkligen bara 5200 bytes stor? finns inget overhead?
Det finns garanterat en overhead för varje tabell, tabellen information måste sparas undan någonstans, hur stor den blir har jag ingen aning om, men det är nog inte så mycket.. Dessutom så haltar din uträkning lite eftersom tabellen skulle ta 5kB per användare om det var 1300 poster, och med 100 användare med 1300 poster så blir det 500 kB osv osv...
requez skrev:
Sen är vi ju cirka 50 aktiva användare, så det blir ju en del rader... jag menar det gäller ju att läsa in allt en gång för alla och sedan loopa igenom trådarna o sätta rätt css-klasser och inte göra en db fråga för varje post DÅ blir det långsamt
Nu vet jag inte hur du gör dina sql frågor men jag hade försökt göra någon joins mellan din post tabell och din "harbesökttabell" när du hämtar ut information om din post så du i den frågan kan få reda på om användaren har läst posten eller ej...
Tänk på att med integer kan du bara lagra tal upp till 65000, så om du har post id eller användare id som är större än det så kan du inte använda integers utan måste upp till bigint/long...
Senaste post id: 68227, bigint blir det...
Gladh skrev:
Nu vet jag inte hur du gör dina sql frågor men jag hade försökt göra någon joins mellan din post tabell och din "harbesökttabell" när du hämtar ut information om din post så du i den frågan kan få reda på om användaren har läst posten eller ej...
- M
Ja, så måste det ju bli, borde inte bli så nedslöande då det bara är att kolla om en nuffra finns...
För att spara ytterligare utrymme - jag tänka mig att användarna inte är speciellt intresserade att få veta att de missat läsa en post som skapades för en månad sedan. Jag skulle med andra ord bara spara de sidor som besökts de senaste 30 dagarna och sätta alla som är äldre att vara "besökta" redan.
266 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
