--- title: "hur manga har svarat?" type: "forum-thread" url: "https://www.webforum.nu/amne/asp/40488-hur-manga-har-svarat" topic: "ASP" topic_url: "https://www.webforum.nu/amne/asp" author: "eriks" published: "2002-03-28T18:27:15.000Z" updated: "2002-03-29T22:15:36.000Z" replies: 12 views: 401 page: 1 pages: 1 language: "sv-SE" site: "webForum — webforum.nu" rights: "Upphovsrätten till varje inlägg tillhör dess författare." attribution: "Citera som: webForum, https://www.webforum.nu/amne/asp/40488-hur-manga-har-svarat" --- # hur manga har svarat? ## #1 — eriks, 2002-03-28T18:27Z Hej! Jag har ett problem liknande det man borde fa om man vill skapa ett forum som likanr detta (men jag skriver i asp istallet for php). Om man star i forumet ASP, VBScript, sa kan man ju se for alla inlagg hur manga svar de har. Denna uppgift maste val anda vara sparad i ett seperat falt i databasen. Det kanns som om det skulle bli megalangsamt att rakna antalet svar for varje inlagg varje gang sidan laddas. Om man har antalet svar sparade i ett seperat falt i databsen tar det ju visserligen lite mer tid att skriva ett svar, eftersom det maste adderas i specialfaltet ocksa. Vilket ar det basta sattet att gora detta pa? Tack sa mycket! /Erik Permalänk: https://www.webforum.nu/p/40488 ## #2 — Mika3l, 2002-03-28T21:43Z Du kör antal svar i ett eget fält ja. Varje gång någon svarar så plussar man bara på 1. /Mika3l Permalänk: https://www.webforum.nu/p/632406 ## #3 — spango, 2002-03-28T21:50Z Det är betydligt bättre att generera det varje gång man kollar (i.a.f. designmässigt). Hur man gör det beror på databasdesignen (men man lär väl använda någon COUNT(\*) kan man tro). Permalänk: https://www.webforum.nu/p/632409 ## #4 — Erik Juhlin, 2002-03-28T22:02Z Håller med spango. Mycket dumt att lagra onödig data som finns på annat sätt... Permalänk: https://www.webforum.nu/p/632413 ## #5 — Pace, 2002-03-28T22:07Z Håller inte med spango. :e Det rör sig inte om så mycket data (1 st int fält per forum), och det går dessutom snabbare. Permalänk: https://www.webforum.nu/p/632415 ## #6 — Erik Juhlin, 2002-03-28T22:10Z Jag säger som John sagt tidigare att det kan bli fel om man inte kör transactions vilket jag inte tror många här gör... Att lagra data så blir bara kluddigt i längden. Permalänk: https://www.webforum.nu/p/632418 ## #7 — Pace, 2002-03-28T22:11Z Jo det håller jag med om. Men om det bara rör sig om detta fallet så tycker jag man kan ha överseende med det. Permalänk: https://www.webforum.nu/p/632419 ## #8 — Erik Juhlin, 2002-03-28T22:17Z Det är en mycket äcklig design som får mig rysa! :o Permalänk: https://www.webforum.nu/p/632426 ## #9 — spango, 2002-03-28T22:36Z Update anomalies, bristande normalisering, redundans... \*buäh\*! :x Permalänk: https://www.webforum.nu/p/632434 ## #10 — emission, 2002-03-29T00:55Z Nä, så kluddigt bör man inte bygga. Förvisso kan man ju övernormalisera en databas, men att lagra denna information i ett separat fält känns helt galet. Lita på att databasservern faktiskt är rätt bra på att optimera förfarandet. Om man fortfarande tvekar så ska man testa prestandaskillnaden och fråga sig om databasstrukturen verkligen är värd att offra för en minimal skillnad. /g Permalänk: https://www.webforum.nu/p/632454 ## #11 — jarvklo, 2002-03-29T00:55Z > Det kanns som om det skulle bli megalangsamt att rakna antalet svar for varje inlagg varje gang sidan laddas Helt klart \*kan\* det bli tungt. Speciellt om du tänker dig att \*många\* tittar på din sida samtidigt, eller att varje tråd har \*många\* inlägg. > Update anomalies, bristande normalisering, redundans... \*buäh\*! Javisst - men ibland måste man ta smällen att det blir grötigare att koda och svårare att hantera vid ändringar... t.ex. om man bygger system med höga prestandakrav. Ibland är det bättre att lägga all hantering av informationen i databasen vid \*ändringstillfället\* än vid \*läsningstillfället\*. Att räkna poster i realtid, brukar jag ibland likna med följande: Man skall skriva flera exemplar av samma sida på en skrivare, men man startar inte skrivaren förrän någon begär att få läsa sidan. Det är enkelt och strukturellt rent att koda algoritmen, och det fungerar bra vid "liten last", dvs få samtidiga intressenter. Risken är bara att man lastar ner systemet när många samtidigare besökare vill åt informationen samtidigt (tänk dig att 200 pers samtidigt vill åt sidan och det ramaskri den långa kön till skrivaren detta skulle ge ;) ) Att förlagra mellanresultat i egna celler är i "skrivarmetaforen" ovan att likna med att man skriver ut en massa sidor i förväg, så att de 200 personerna samtidigt kan ta varsin lapp direkt, utan att vänta på att skrivaren skall hinna spotta ur sig just deras exemplar. Nackdelen är då t.ex. att det kan bli lite mycket papper över när informationen på sidan ändras, dvs det är knöligare att koda beteendet, och det är kanske inte lika "strukturellt vackert" att tänka sig in i problematiken ;) Med dessa liknelser i bakhuvudet går det att inse att man ibland måste skapa sidan och dess innehåll "på begäran" (när t.ex. innehållet ändras mycket oftare än folk tittar på det eller när det är personligt anpassat till varje individ) även om det medför att folk i värsta fall kan få vänta lite, och att man ibland måste förlagra (eller cachea ;) ) redundanta mellanresultat för att servern skall hinna med. I system med "små" datamängder, är skillnaderna antagligen så små att det inte spelar någon roll vilken variant man väljer (om man har kapacitet över på sin server vill säga!) - och man kanske kan tillåta sig att räkna "direkt", men i system med stora datamängder, eller när systemet måste ligga på en nerlastad server, uppskattar man nog förr eller senare ett val mot prestandaoptimerade algoritmer och så mycket mellanlagringar man bara orkar peta in, även om det innebär att man inför redundans, långsammare uppdatering av ändringar eller mindre "snygga" strukturer... Permalänk: https://www.webforum.nu/p/632455 ## #12 — eriks, 2002-03-29T03:56Z hmmmm. Jag ar "still confused, but on a higher level". Ett problem ar val att alla sajter har liten trafik i borjan och sedan vaxer de (forhoppningvis). Ska man da satta sig och koda om, nar sajten borjar bli stor? Tack for alla svar an sa lange... Permalänk: https://www.webforum.nu/p/632478 ## #13 — spango, 2002-03-29T22:15Z Tja... > *Ursprungligen av eriks* **Ett problem ar val att alla sajter har liten trafik i borjan och sedan vaxer de (forhoppningvis). Ska man da satta sig och koda om, nar sajten borjar bli stor?** Vissa menar att det är helt rätt att göra så. > *Rules of Optimization: > Rule 1: Don't do it. > Rule 2 (for experts only): Don't do it yet.* > \- M.A. Jackson > > *More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.* > \- W.A. Wulf > > *We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.* > \- Donald Knuth > > *The best is the enemy of the good.* > \- Voltaire ([källa](http://www-2.cs.cmu.edu/~jch/java/optimization.html)) Observera att det där är snubbar som *verkligen* kan sina saker. Permalänk: https://www.webforum.nu/p/632713 --- Tråden på webben: https://www.webforum.nu/amne/asp/40488-hur-manga-har-svarat