CIO Tech Eksperten IT-JOB IT-Kurser Events Podcast Søg

Log ind eller opret profil

Du kan også logge ind via nedenstående tjenester

htx98i17 Professor

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

Synes godt om

arne_v Ekspert

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..

Synes godt om

arne_v Ekspert

29. december 2008 - 17:49 #2

yk yk

forumid, INT, PK
tidspunkt, DATETIME, PK

Synes godt om

htx98i17 Professor

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?

Synes godt om

htx98i17 Professor

29. december 2008 - 18:01 #4

17:49:47: primary key på begge felter?

Synes godt om

arne_v Ekspert

29. december 2008 - 18:04 #5

eller er det jo ikke unikt ...

Synes godt om

arne_v Ekspert

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.

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

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?

Synes godt om

arne_v Ekspert

29. december 2008 - 18:12 #9

du kan ikke få en unik PK i den

Synes godt om

htx98i17 Professor

29. december 2008 - 18:13 #10

hvorfor SKAL der være en unik PK hvis der er INDEX på forumid?

Synes godt om

htx98i17 Professor

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?

Synes godt om

arne_v Ekspert

29. december 2008 - 18:22 #12

man har altid PK i en tabel

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

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?

Synes godt om

arne_v Ekspert

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.

Synes godt om

htx98i17 Professor

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?

Synes godt om

htx98i17 Professor

29. december 2008 - 18:36 #17

der kom lige en "Og der er det eneste fornuftige." for meget med i sidste indlæg.

Synes godt om

arne_v Ekspert

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.

Synes godt om

arne_v Ekspert

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.

Synes godt om

htx98i17 Professor

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.

Synes godt om

htx98i17 Professor

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?

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

29. december 2008 - 19:00 #23

jamen hov, kan der godt være dubletter af PK ?

Synes godt om

arne_v Ekspert

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.

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

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?

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

29. december 2008 - 23:08 #28

men der ville ingen fejl komme ved insert, hvis tidspunkt ikke havde PK?

Synes godt om

arne_v Ekspert

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

Synes godt om

htx98i17 Professor

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

Synes godt om

arne_v Ekspert

30. december 2008 - 04:29 #31

så smider jeg et svar

Synes godt om

Ny bruger Nybegynder

Din løsning...

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.

Følg dette spørgsmål

Opret Preview

SQL kurser

Computerworld tilbyder specialiserede kurser i database-management

Se alle SQL kurser

Flere spørgsmål fra MySQL kategorien

Titel	Indlæg	Oprettet	Seneste aktivitet
Problemer med Æ, Ø og Å ved søgning Af cht22 i MySQL	6	01/05/202512:30	01/05/202517:22
Kan ikke få forbindelse til min database Af KurtG i MySQL	5	20/03/202520:07	21/03/202513:10
Kan jeg lave en "søg og erstat" i databasen Af a3-seo.dk i MySQL	4	28/12/202407:53	29/12/202404:41
Auto Faktura.. Af SommerFyr i MySQL	21	13/08/202415:08	15/08/202417:54
Hjemmeside med bruger login Af FennekTheFox i MySQL	3	22/06/202411:29	29/06/202409:13

Se alle spørgsmål i kategorien Opret spørgsmål

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester

Alle kategorier på Eksperten

Seneste artiklerRSS