08. juli 2001 - 22:51Der er
57 kommentarer og 3 løsninger
Database-opbygning til stor side !?
Hejsa alle...
Jeg håber, at der er en eller flere kloge hoveder, som kan hjælpe mig med et lille problem. Det kræver nok at I tænker jeg om, hvis I ikke har arbejdet med dette før ... men, her kommer det:
Jeg vil med en side som chart.dk som forbillede, lave en side, som kan holde statistik over en masse andre sider. (sådan som chart.dk fungerer) ...men, men, men.. hvordan skal jeg lave database opbygningen !? I skal tænke på, at man skal kunne gå tilbage til en speciel dag og så se timefordelingen over sine besøg den dag... dvs. der skal registeres en masse ?
Hvis hver besøg skal registeres som en post i en database vil der jo lynhurtigt komme MANGE 1000 poster, som kan tage lang tid at søge i ....
Håber at kunne få noget hjælp, eller i det mindste en god diskussion!!!!
Hvis du bruger, og det er nok et must på sådan et stort site, mySQL eller MS SQL så vil søgning i en tabel med 1.000.000+ records ikke tage mange sekunder, alt efter om det er tekst eller tal søgning.
Desuden hvis du har et index på et felt gør det søgning langt hurtigere, har jeg ladet mig fortælle, men har ikke prøvet det selv da jeg ikke har lavet nogle store sites.
tdaugaard: Hvis vi kigger på chart.dk - deres nr. 1 bruger er dating.dk med omkring 65000 besøg pr. dag... de vil så lave lige knap 2.000.000 poster pr. måned! Hvis vi så siger, at de lige vil 1 år tilbage, så er det pludselig mange poster..!?
Stadigvæk er det den eneste løsning... Ofte laver vi på min arbejdsplads et backup pr. 50.000.000 poster og sletter så disse poster fra databasen.. Hvis vi så senere skal bruge dataene smider vi den CD vi skal bruge i Drevet og smider dataene ind i SQL Serveren igen.
Synes godt om
Slettet bruger
08. juli 2001 - 23:01#6
Du skal benytte dig af normaliseringsform 1, 2 og 3 måske endda 4 så dine databaserelationer bliver så effektive som mulige.
aaahh, 1.000.000 poster er sq mange. Mener at have hørt fra alvion at et index på et felt kan svare sig at lave når der er mere en 10 eller 100.000 poster i db\'en...
schulze-> Normaliseringen er ikke der hvor hovedvægten skal lægges.. Jo mere Normalisering des mere Kodning/Joins. Jeg finder som regel at Boyce-Codds normalform er passende til webapplikationer.
Hmm .. men jeg kan se at selvom jeg ikke aner hvad det er har jeg åbenbart en lidt medfødt evne for normalisering for jeg kan se ud fra et af eksemplerne (anden normalform tror jeg) så er det noget jeg selv har lavet før, altså den slags normalform ..
TOTALT! Access kan slet ikke klare den slags trafik. Bare dating.dk vil lave i gns. 45 poster hvert minut 24/7... det kan Access slet ikke klare i længden.
At indsætte 2 random-tal (et 4-cifret og et 5-cifret) tager ca. 3 sek. for at indsætte 500 poster... !?! (dette er self. i en løkke, og ikke nye scripts hver gang..)
Ja det kan man godt med SQL Syntaksen Create table... Men at have flere tabeller vil sikkert være mere sløvende end at have få tabeller med mange poster. (pga. SQL Serverens caching osv.)
svarer direkte til det første: Du sletter bare gamle records i databasen længere er den ikke vel?... Eller opret et timesheet med de 24 timer hvor man så vælger et ud fra dagen og hvis der ikke er noget opretter man et nyt! det er meget enkelt =)
Well, #3 må vel være normalisering af databasen således at du opnår den bedst mulige optimering af tabeller osv.
Jeg kunne forestille mig måske een tabel til IP\'ere (id - IP) og een til hits således at du kan tælle både unikke og pageviews, uden at have duplicate IP\'s i \"hits\" tabellen.
1. Du har sikkert ikke brug for avancerede ting som subselects o.lign. derfor er mySQL et glimrende valg da denne er ekstrem hurtig (Til et bestemt punkt)men netop mangler nogle af de mere avancerede funktioner. Men på den anden side vil mySQL i en realworld applikation med mange hits begynde at blive noget tung at danse med ved omkring ca. 2 mio records. Andre alternative valg kunne derfor være PostgreSQL eller Sybase ASE 11 (Begge gratis svjh.)
2. Vil tro det er det rigtige, men lav evt. nogle benchmark tests på databasen hvor du leger med tabelstørrelse normalisering osv.
3. Hvis du virkelig satser på at lave et holdbart projekt finder du tegnedrengen frem og køber en Oracle som sparker så meget ... at du ikke tør drømme om det. (Hvis nogle siger DB2 nu så kig lige på: http://www.oracle.com/features/9i/index.html?ad_benchmark.html )
så lav det timesheet, det er den bedste løsning og så skal man kun oprette 1 om dagen! =) man skal vel ikke kunne se hver eneste aktive bruger forhelvede men bare antal!.........
Moonduck man køber først den slags når det andet ikke er nok! personlig har jeg en oracle licens men aldrig brugt den..... sql server er passende mysql fin!
dark-nisse:> snak da ordentligt! Hvis du skal lave ordentlige statistikker skal du bruge en post til HVER besøgende. Du kan selvfølgeligt også lave een post med felter der bliver lagt 1 til, men så kan du ikke lave en \"peak-time\" statistik!
dark-nisse:> Nej, ikke nødvendigvis. Jeg har hørt om Oracle programmører .. at man ligefrem skal programmere \"databasen\" .. dunno, men når noget er dyrt behøver det ikke at være tidskrævende.
tdaugaard>> Nej oracle er ikke svær.. Det kræver blot at man sætter sig lidt ind i tingene.
dark-nisse>> Hvis man bygger databasen fornuftigt op og kender forskellene mellem de to DBMS\'er man skifter mellem kan man godt konvertere..
Men ofte er et databaseskift lagt i hænderne på de forkerte lig med datatab eller meget tid offline. Men selvfølgelig er det muligt at gøre korrekt, men hvis man har pengene er det nemmere at købe det rigtige udstyr fra starten.
<dårlig sammenligning> Det er jo som bekendt også svært for schumacher at skifte racerbilen ud mens den kører, og stadig vinde løbet. </dårlig sammenligning>
hehe! not funny! men hvis hans side ikke går så godt som mange portaler desvære ikke gør, er det dumt at stå med en oracle licens! det er på den måde mange går konkurs bruger penge som ikke er nødvendige! erindrer at jubii var nede i 2 dage da de skiftede server\'ne ud...
hehe hvis du vil slippe for en overfyldt db kan du lave et table i mysql: med et felt for alle 24 timer (de kan nok ikke hedde fx:1)...
så når en bruger kommer ind putter han 1 til databasen på det pågældenede tidspunkt fx 12:00... så kan du klare dig med 365 pr side pr år! ikke 500.000.000.000.000.000 og der vil ikke blive overbelastning!...
På denne måde kan du nemt give statestik evt lave et felt for hits idag hvor der bliver talt hvis han ikke har været der før! (tip: cookies til hele lortet)......
Tja... den idé tror jeg faktisk, at jeg vil arbejde lidt på! Men, kan man på den måde også tjekke alle mulige andre ting !? Når man ikke logger IP osv. så kan det være svært at opdage snyd !??
Okay nu fatter jeg ikke hvad det er du vil dark-nisse.... Kan du ikke prøve at forklare dig lidt nærmere evt. tegne dit forslag til en databaseopbygning.
Du vil altså lave 24 kolonner pr. site og kun tælle antal hits pr. time pr. site?
det er måden at gøre det han vil på jo!.... dna har du fattet det?...
du kan evt smide et felt mere i og tælle pr dag! lægge dem sammen og få pr uge, måned, år what ever... han kan lave meget mere end man skulle tro , jeg hjælper ham bare ind på det ubeviste...
dna:> Hmm .. men, men .. spørgsmålet er om du vil sidde og skulle lave databasen om til mySQL når den tid kommer .. der er jo både konverteringen men også evt. SQL kald der skal laves lidt om...
nnæ... det kan du vel nok have ret i ... men, selvom det var dark-nisse der kom med det bedste svar, så har jeg alligevel valgt at dele point´ene ud efter deltagelse....
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.
