29. december 2008 - 17:39
Der er
30 kommentarer og 1 løsning
tabel til registrering af visninger af forumindlæg
Jeg vil registrere antal visninger af forumindlæg. Forumindlæg har et unikt id. Hvordan skal tabelstrukturen se ud for registreringen af anatal visninger af et indlæg? I må meget gerne komme med holdninger om følgende forslag: En tabel med én column: forumid (INT) INDEX SQL for hent: SELECT COUNT(forumid) AS antal FROM tabel WHERE id = 1 GROUP BY forumid En tabel med én column: forumid (INT) PRIMARY KEY SQL for hent: SELECT COUNT(forumid) AS antal FROM tabel WHERE id = 1 GROUP BY forumid En tabel med to columns : forumid (INT) INDEX antal_visninger (INT) SQL for reg: REPLACE INTO tabel (forumid,antal_visninger) VALUES (1,2) SQLfor hent: SELECT antal_visninger FROM tabel WHERE forumid = 1
Annonceindlæg tema
Cloud & AI
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
29. december 2008 - 17:49
#1
Jeg ville nok lave en tabel med 2 kolonner: forumid, INT, PK tidspunkt, DATETIME fordi så kan du lave både total visninger, antal visninger per år eller per måned etc..
29. december 2008 - 17:49
#2
yk yk forumid, INT, PK tidspunkt, DATETIME, PK
29. december 2008 - 17:57
#3
så den 3. mulighed: En tabel med to columns : forumid (INT) INDEX antal_visninger (INT) SQL for reg: REPLACE INTO tabel (forumid,antal_visninger) VALUES (1,2) SQLfor hent: SELECT antal_visninger FROM tabel WHERE forumid = 1 Kan godt skrottes? Hvis jeg ikke får brug for dato for visninger, hvilken af de to første ekspempler ville du så vælge?
29. december 2008 - 18:01
#4
17:49:47: primary key på begge felter?
29. december 2008 - 18:04
#5
eller er det jo ikke unikt ...
29. december 2008 - 18:06
#6
alternativet til forumid, INT, PK tidspunkt, DATETIME, PK må være id, INT, PK, AUTO INCREMENET forumid, INT fordi du skl have en PK. Og helt ærligt, hvis du har to felter, hvorfor så ikke have tidspunktet, så du evt. kan lave noget statistik senere.
29. december 2008 - 18:07
#7
forumid (INT) PRIMARY KEY for som sagt problemer med unik PK forumid (INT) INDEX antal_visninger (INT) vil enten give samtidigheds problemer eller skalerings problemer
29. december 2008 - 18:07
#8
hehe det er så korrekt :) men jeg hælder selv mest til En tabel med én column: forumid (INT) INDEX eller PK?
29. december 2008 - 18:12
#9
du kan ikke få en unik PK i den
29. december 2008 - 18:13
#10
hvorfor SKAL der være en unik PK hvis der er INDEX på forumid?
29. december 2008 - 18:14
#11
forumid (INT) INDEX antal_visninger (INT) vil enten give samtidigheds problemer eller skalerings problemer samtidighedsproblemer vil der vel også komme med: forumid, INT, PK tidspunkt, DATETIME, PK eller det vil der så ikke pga 2 PK's, men vil posten så blive gemt? og hvad mener du med skaleringsproblemer?
29. december 2008 - 18:22
#12
man har altid PK i en tabel
29. december 2008 - 18:24
#13
det giver langt mindre samtidigheds problemer at to sessions indsætter hver sin række end at de skal opdatere samme værdi måden at løse samtdigheds problemet på kunne være at låse hele tabellen (for MyISAM) og så vil det gå så langsomt med mange samtidige opdateringer
29. december 2008 - 18:24
#14
18:22:36 også hvis man har et index? PK har man vel kun hvis man skal bruge det til noget?
29. december 2008 - 18:33
#15
Man har *altid* PK i en tabel. Jeg kan ikke huske om MySQL enforcer det, men det er der andre databaser som gør. Og der er det eneste fornuftige.
29. december 2008 - 18:36
#16
Og der er det eneste fornuftige: Jeg elsker selv principper, men her mangler der altså en fornuftig forklaring. Og der er det eneste fornuftige. forumid, INT, PK tidspunkt, DATETIME, PK hvis der kommer en samtidighed her, hvad sker der så? vil den ene post vente?
29. december 2008 - 18:36
#17
der kom lige en "Og der er det eneste fornuftige." for meget med i sidste indlæg.
29. december 2008 - 18:40
#18
Problemet hvis man ikke har en PK (en unik nøgle) er at der ikke er en måde hvorpå man altid kan få fat i en ebstemt række. Det er en meget sund egenskab at man altid kan få fat i en bestemt række. Hvis du søger i DB kategorierne her på E vil du finde masser af spørgsmål, hvor folk har store problemer p.g.a. manglende PK.
29. december 2008 - 18:43
#19
for forumid, INT, PK tidspunkt, DATETIME, PK så håndterer MySQL selv INSERT samtidigheds problemet. Og der er ikk e ret meget overhead, fordi alt hvad der skal synkroniseres er en pegepinden til hvor langt man er kommet med rækkerne. Hvis der er 477 rækker i tabellen og der skal ske to insert "samtdigt" så skal man bare sikre sig at de får tildelt række 478 og 479. Så kan de skrive data parallelt.
29. december 2008 - 18:44
#20
Jeg ved godt hvor du vil hen :) og har også set problemer med manglende PK. Jeg spørger for at fremprovokere et svar der svarer på hvorfor jeg i mit tilfælde SKAL have en PK, nu når jeg ikke har brug for at hente en bestemt række. Jeg skal jo blot registrere hvor mange visninger et forumindlæg har haft.
29. december 2008 - 18:46
#21
jeg laver en løsning med forumid, INT, PK tidspunkt, DATETIME, PK for princippets skyld. Hvordan håndtere INSERT selv samtidighedsproblemet? vil den ene post vente på den anden bliver færdig?
29. december 2008 - 18:54
#22
Logikken kan laves som: lock (bundpointer) { minpointer = bundpointer bundpointer++ } write(minpointer, række) det der skal laves mens der er låst tager meget jort tid måske 1/100 af den tid det tager at lave selve write - derfor er det meget hurtigt
29. december 2008 - 19:00
#23
jamen hov, kan der godt være dubletter af PK ?
29. december 2008 - 19:35
#24
Nej. Den samlede PK skal være unik. Men der kan godt være dubletter i felter som indgår i PK.
29. december 2008 - 19:36
#25
Ah. Du er bekymret for 2 med samme tidspunkt. Udmærket pointe. Så er vi ovre i: id, INT, PK, AUTO INCREMENT forumid, INT tidspunkt, DATETIME
29. december 2008 - 22:44
#26
nemlig men hvad ville der komme ud af at at der var 2 med samme tidspunkt med forumid, INT, PK tidspunkt, DATETIME, PK ? og hvad ville PK i tidspunkt, DATETIME, PK gøre af nytte?
29. december 2008 - 23:04
#27
Med: forumid, INT, PK tidspunkt, DATETIME, PK så ville et forsøg på at indsætte med samme forumid og samem tidspunkt (DATETIME kører kun med præcision på sekunder i databasen) give en fejl ved INSERT
29. december 2008 - 23:08
#28
men der ville ingen fejl komme ved insert, hvis tidspunkt ikke havde PK?
29. december 2008 - 23:20
#29
hvis forumid var PK fremfor (forumid,tidspunkt) så ville du få fejl hvis der blev forsøgt at indsætte mere end en række per forumid - det er næppe ønskværdigt
29. december 2008 - 23:28
#30
det mente jeg nok det var det der (forumid,tidspunkt) der er nyt for mig du må hellere få nogle point :) tak for hjælpen
30. december 2008 - 04:29
#31
så smider jeg et svar
Computerworld tilbyder specialiserede kurser i database-management