primary key

[VD]

Hei

 

Jeg har ett lite dillemma her.

 

Jeg har ett felt id int(5) som er primary key.

 

når jeg legger til en rad i databasen så blir det lagt inn ett tall automatisk der

 

feks:

id

1

2

3

meen om jeg sletter alt som har med feks id 2 å gjøre og legger inn en ny oppføring så blir det:

id

1

3

4

Er det en måte å trimme dette på slik at de ledige tallene under blir fyllt opp?

[terjeelde]

Ikke slemt ment, men det høres litt ut som om du prøver å løse feil problem på feil måte.

 

Fint om du kan hjelpe oss å forstå litt bedre... Hvorfor er det ett problem om det blir hull i ID-serien?

 

Og hvilke database bruker du?

[VD]

Hei hei.

 

Bruker mysql.

 

Jeg vil bare ha det til å se ryddig og fint ut. =) Og også for å få det til. Er ikke kult med tomme felter i en tallrekke uansett sammenheng (iallefall i dette tilfellet) =)

[blackbrrd]

Ikke bry deg om de tomme feltene i tallrekken, det er ingen som har tenkt å sjekke en tabell med en million rader og se om det mangler noen tall i rekken.

[terjeelde]

Jeg vil bare ha det til å se ryddig og fint ut. =) Og også for å få det til. Er ikke kult med tomme felter i en tallrekke uansett sammenheng (iallefall i dette tilfellet) =)

 

Kjempefint at du vil gjøre ting ryddig og fint, men i dette tilfelle blir det faktisk ryddigst å ikke gjenn-bruke en gammel ID.

 

Se for deg at du har to tabeller, hvor du peker fra tabell B til ID i tabell A. Så sletter du en rad fra A, og gjen-bruker IDen. Da kan du ha en rad fra tabell B som peker til feil rad i tabell A. Det er mye bedre at den peker til en manglende ID. Det blir både mer riktig, og lettere å finne ut at noe er feil (dersom det er det).

[blackbrrd]

Jeg vil bare ha det til å se ryddig og fint ut. =) Og også for å få det til. Er ikke kult med tomme felter i en tallrekke uansett sammenheng (iallefall i dette tilfellet) =)

 

Kjempefint at du vil gjøre ting ryddig og fint, men i dette tilfelle blir det faktisk ryddigst å ikke gjenn-bruke en gammel ID.

 

Se for deg at du har to tabeller, hvor du peker fra tabell B til ID i tabell A. Så sletter du en rad fra A, og gjen-bruker IDen. Da kan du ha en rad fra tabell B som peker til feil rad i tabell A. Det er mye bedre at den peker til en manglende ID. Det blir både mer riktig, og lettere å finne ut at noe er feil (dersom det er det).

Nå høres det ut som du ikke har foreign keys, noe som er veldig lite ryddig.

[terjeelde]

Nå høres det ut som du ikke har foreign keys, noe som er veldig lite ryddig.

 

Sant, sant.

 

Egentlig har jeg mest lyst å anbefale PostgreSQL, som er kraftigere, har bedre dokumentasjon, og mer behagelig grensesnitt.

 

Vil man være ryddig bør man også ha ACID, transaksjoner etc, noe som for MySQL betyr InnoDB. Da er PostgreSQL også en raskere database.

[blackbrrd]

Sant det, jeg bruker PostgreSQL på jobben og ville brukt den privat også.

 

PostgreSQL skalerer veldig pent med diskIO, Ram og CPU-er.

 

PostgreSQL 8.4 kommer snart og har en god del snasne features i tillegg.

Endret 18. juni 2009 av blackbrrd

[terjeelde]

PostgreSQL 8.4 kommer snart og har en god del snasne features i tillegg.

 

Fullstendig malapropos, men må si det: "WITH RECURSION" WOHOO!!

[BlueEAGLE]

en ting som ikke har blitt nevnt her er at nummerserien i primærnøklene ikke nødvendigvis skal vises til bruker med mindre det er et grensesnitt hvor denne nøkkelen blir brukt for identifikasjon.

 

Hvis du skal ha ti påfølgende rader numerert så vil du holde telleren utenfor og bruke kode som:

 

SELECT * FROM tabell LIMIT $offset, $row_count

 

hvor $offset er den første raden i gruppen du vil vise og $row_count er hvor mange oppføringer du vil vise.

 

Typisk så er $offset et produkt av $row_count så veldig ofte så vil $offset = $row_count * $page_id, hvor $page_id er "sidenummeret" i listen.

 

Håper det hjelper deg til å gjøre det jeg tror du forsøker å gjøre.

[mysjkin]

en annen (og egentlig eneste) løsning dersom du på død og liv vil ha løpende verdier i primærnøklen din er å aldri slette poster, men ha et felt som viser om posten er gyldig eller ikke og så skjekke for denne verdien i spørringer evt lage et view som filterer på dette.

 

Men i utgangspunktet er jeg enig med de andre her - la primærnøklen være databasens sak.

 

M.