ID, points og uendeligt antal kommentare. Hvordan?

Hvis databasen skal være normaliseret skal du vel have en tabel-struktur som:

post
----

postid (PK)
point
xxxx

kommentar
---------

kommnetarid (PK)
post (FK)
tekst
yyyy

jeg ville ligge kommentarene i en tabel for sig selv. du laver så et id som relaterer til posten.

Eller hvis du vil beholde muligheden for at se hvem der har givet
hvor mange point:

post
----

postid (PK)
xxxx

kommentar
---------

kommnetarid (PK)
post (FK)
point
tekst
yyyy

[xxxx og yyyy repræsenterer bare 0-mange øvrige felter du måtte have brug for]

Jamen selv om jeg smider kommentare i en anden tabel, så vil disse jo stadig ligge "vandret" i databasen. Og da jeg ikke kan gætte mig til, hvor mange kommentare der bliver skrevet, er dette heller ikke smart.

Jeg har overvejet, om det kunne laves som lodret i stedet. Hvor feltets navn blot bliver ID'et til den aktuelle post - og nedenfor kommer alle kommentarene så. Nogen ulemper ved dette ?

Den tabel-strukturjeg har angiver er "lodret".

kommentarid er unik.

Men der kan godt være flere records med samme postid i kommentar tabellen.

"Men der kan godt være flere records med samme postid i kommentar tabellen."
Forstod jeg ikke helt. Der er jo ikke 2 poster som har samme ID.

Problemet med modellen, der benytter lodret struktur er, at jeg igen ikke ved hvor mange poster der vil blive lavet. Så enten skal der automatisk blive lavet et felt i kommentar-tabellen, når en post oprettes, eller også skal feltet først oprettes, når den første kommentar "kommer ind".

Ville sidstnævnte ikke være smartest ? Hvordan tjekker man i givet fald, om et felt eksistere ?

Jo 1 record i post tabellen vil svare til 0-mange records i kommentartabellen.

Der skal tilføjes en ny record til kommentar tabellen hver gang der laves en kommentar
med henvisbing til den rigtige record i post tabellen.

Ok, jeg forstår ikke hvad du mener. Men kan flg. bruges :

Post-tabel (har et ID nr. for hver post - ingen gengangere)

Point-tabel (Feltet ID får samme værdi som en aktuel post, feltet points indeholder karakteren)

Kommentar-tabel (Har et primary ID felt (skal egentlig ikke bruges til noget, men kan blive brugbart senere. Når en kommentar skrives, oprettes et felt automatisk med samme ID nr. som posten har. Herunder lægges alle kommentarer)

et lille eksempel:

poster:
    postid = 1
    text = "hello world"


kommentarer:
    id = [autonummering]
    postid = 1
    text = "test"

    id = [autonummering]
    postid = 1
    text = "test 2"


dette giver 2 kommentarer til posten med postid=1

Aah, IC. Du opretter altså en ny vandret række for hver kommentar.

Det kan jeg godt se det smarte i. Så får man ikke 9000 kommentare vandret.

Dette er -måden- at gøre det på. I hvert fald, som arne siger, hvis databasen skal være normaliseret.

IC.

Men er min løsning ikke "hurtigere" ?
Nu skal den jo hen og finde/søge de poster, som har IDet X. Ved min løsning kan man blot lave en "direkte" select - hvis i forstår

Ja sommetider kan det være lidt hurtigere med en unormaliseret
database.

Men hvis du husker at lave INDEX på postid feltet i kommentar
tabellen, så burde det ikke være noget problem i dette tilfælde.

(men uden INDEX så vil det tage lidt tid)

Hvad vil det sige at lave Index på feltet ?

Syntax:

CREATE INDEX kommentar_post_ix ON kommentar (postid);

og den gør at MySQL laver et index således at den lynhurtigt kan
finde alle records i kommentar med postid=27 i stedetfor at skulle
lede hele tabellen igennem efter records med postid=27.

Det var smart. Det må jeg forske i lidt senere :)
Et sådan index laves blot efter, at tabellen er oprettet, ikke sandt ?

Ja.

(du behøver ikke oprette index på primær nøgler - det sker automatisk, men
felter du bruger til join og where betingelser som ikke er primær-nøgler
er det ofte en god eide at sætte index på)

IC. Jamen mange tak for hjælpen så :-D