27. maj 2010 - 15:24Der er
4 kommentarer og 1 løsning
Lave statistik over viste vare
I forbindelse med en webshop har jeg brug for at registrer hvor mange gange hvert produkt er vist. Indtil nu har jeg registreret hver visning som en række i en tabel, men efter ca 6 månder fylder den tabel nu 250 MB. Derfor vil jeg gerne lave en løsning som ikke bruger så meget database plads.
Jeg har overvejet at have en kollone for hver produkt med antal besøg, men jeg er lidt i tvivl om hvordan jeg koder det mest effektivt og uden at miste nogle visninger.
Er det noget med noget singleton? bør man skrive hvert request med det samme, eller kun skrive engang imellem?
Skal virksomheder stå stærkere mod angreb og kunne udvikle sig, skal sikkerhed, drift og forretning tænkes sammen. Det er tanken bag Jysk IT’s ambition om at skabe en “sikker fremtid” for kunderne.
Du kan fortsaette som hidtil. 250 MB er jo reelt ikke ret meget.
Du kan lave en lille bitte tabel med: vareid,PK,FK counter og opdatere den hver gang. Ved hoej aktivitet og hoej transaction isolation level vil den kunne blive flaskehals i din app. Du kan do hjaelpe lidt ved at putte det i en seperat uafhaengig transaktion.
Du kan lave samme tabel og have en in memory counter (e.eks. i singleton) som skrives tilbage til databasen hver N transaktion eller hver M sekund eller en kombination af dette. Hvis server crasher saa mister du lidt visninger.
Du kan udvide den sidste loesning med at replikere den in memory counter mellem cluster noderne, saaledes at du ikke taber data, hvis en enkelt node gaar ned. Det kraever lidt at faa sat op saa det er effektivt. Og forudsaetter mere end 1 server.
Hej Arne, og mange tak for din kommentar! Er der noget performance eller andre overvejelser i at du forslår at lave det i en sepperat tabel, istedet for at lave det direkte i vare tabellen?
Flere grunde: - hvis man gaar meget op i at modellere virkeligheden, saa mener jeg faktisk ikke at antal visninger er en egenskab ved produktet - hvis man retter i en eksisternde tabel struktur er der altid risiko for at det kraever aendringer i noget kode der bruger tabellen - jeg gaetter paa (men uden at have noget at begrunde det med) at det vil vaere hurtigere at laese en stor record og opdatere en lille record fremfor at laese og opdatere en store record - dette vil naturligvis vaere database og versions specifik
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
