mboost-dp1
Lagermetode til debatforum?
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Der bliver kun indexeret, hvis du beder om det. Men det kan der skam også være fordel i, fx. til fritekst-søgning.
Hvis ikke der bliver tilføjet mange i sekundet, er den slags slet ikke noget problem, performance-mæssigt.
(Og jeg tænker ikke på når du indsætter data her i starten, men i den daglige drift.)
Hvis ikke der bliver tilføjet mange i sekundet, er den slags slet ikke noget problem, performance-mæssigt.
(Og jeg tænker ikke på når du indsætter data her i starten, men i den daglige drift.)
#relationsdatabaser
Et forum med en flad struktur 1 tråd + M indlæg passer perfekt til en relations database.
Et forum med en træ struktur hvor indlæg er hægtet op på andre indlæg passer ikke helt så godt til en relations database. Men med lidt arbejde evt. brug af ikke standard SQL kan man dog få det til at virke.
Et forum med en flad struktur 1 tråd + M indlæg passer perfekt til en relations database.
Et forum med en træ struktur hvor indlæg er hægtet op på andre indlæg passer ikke helt så godt til en relations database. Men med lidt arbejde evt. brug af ikke standard SQL kan man dog få det til at virke.
arne_v (6) skrev:#4
Har du meget skriveglade brugere?
De fleste databaser har en CLOB type som kan klare ihvertfald 1 GB. Det svarer til ca. 500000 sider A4 sider.
:-)
Jeg har ikke praktisk erfaring med DB og har været i tvivl om hvor meget der er "meget" i en DB :) - Det var godt at få lidt at relatere til.
Ud fra hvad i skriver her er der altså en fordel i at holde data i så få tabeller som muligt frem for at have mange tabeller som krydsrefererer til hinanden?
Det er fuldstændigt ligemeget for dit forum- det konkluderer jeg fordi at bare det du kunne finde på at spørge om det implicerer at du ikke kører din egen server der er tungt belastet af mange brugere.
Den slags detaljer kan du vente med at tænke på til du har fundet ud af at bruge en database.
Indtil videre skal du bare være glad for at der er automatiske locks på når du skriver/læser,dataen resistent og du kan benytte SQL.
Den slags detaljer kan du vente med at tænke på til du har fundet ud af at bruge en database.
Indtil videre skal du bare være glad for at der er automatiske locks på når du skriver/læser,dataen resistent og du kan benytte SQL.
KC (11) skrev:Ud fra hvad i skriver her er der altså en fordel i at holde data i så få tabeller som muligt frem for at have mange tabeller som krydsrefererer til hinanden?
Du bør vælge den tabelstruktur som:
- passer til din problem stilling
- passer til en relations database
Det giver sandsynligvis et antal tabeller som skal joines sammen i diverse queries.
fidomuh (15) skrev:#14
Umiddelbart vil jeg tro han mener at du ikke vil maerke nogen forskel i performance, til dit brug.
Det handler mere om hvad du helst vil arbejde med :)
Tak, med den vinkel gav sætningen (uden kommaer) mere mening. Jeg vil helst arbejde med det som også fungerer, når der kommer mere pres på programmet/siden.
KC (16) skrev:Jeg vil helst arbejde med det som også fungerer, når der kommer mere pres på programmet/siden.
Jeg tror du skal tænke meget mere på detaljerne. At joine tabeller er meget meget billigt, ikke noget du skal tænke over i dit system. (Og det kan jeg sige med meeeget stor sandsynlighed, uden at vide mere end du siger i #1.)
Men en lille bug kan betyder at du overfører ALLE indlæg, hvor du kun skal bruge en enkelt tråd, og efterfølgende smider dem væk du ikke skal bruge.
Jeg har set performance-forbedringer i "hundreder af gange"-klassen blot ved at tilføje et index, hvilket kan gøres med et par klik i fx. phpMyAdmin.
Så design et system som er nemt at arbejde med. Skriv din kode på en måde så den er overskuelig og nem at forstå, det reducerer chancen for at det gør noget andet end du egentlig mener.
Hvis du gør det, er det formentlig intet problem at vente med at tænke på performance, til det faktisk er et problem.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.