auto increment

hvorfor ikke id int(4) not null auto_increment?

Int er så passé :)

bigint er jo også en mulighed...

Eller SMALLINT, den kan holde til65535, hvis du laver den UNSIGNED.

SMALLINT er ALT for lille til en primary key. int eller bigint er de eneste, som giver mening i sådan en situation.

BIGINT: 18446744073709551615, så løber du ikke tør foreæøbig ;o)

mufoxe -> 65535 er rigeligt til mange tabeller.

Jo, for jeg forsøger at lave en database over alle myrer i hele verden! :)

Du har ret detox, men det er dumt at begrænse sig. Især fordi det er så vigtig en værdi. Det lidt ligesom folk, som vælger at bruge en varchar(20) i stedet for en varchar(255) for at spare plads. I princippet betyder det ikke noget om den er 20 tegn lang eller 255 tegn lang, især fordi en varchar kun fylder det antal tegn, som er brugt.

Min pointe er at det er vigtigt at dække sig ind for fremtiden og det gøres bedst ved at bruge en int eller en bigint.

Der er nogen praktiske fordele ved at bruge int fremfor bigint.

Hvilke er det?

Supporten for 32 bit integers er betydeligt bedre end supporten for 64
bit integers i mange typer applikationer.

Og mange vil mene at det ikke er et mål at lave databasen så "flink" som
mulig men derimod et mål at lave den så "restriktiv" som mulig.

Hvsi der ikke må være mere end 64K records i en tabel qua problem stillinge,
så er en 16 bit unsigned integer primary key jo en løsning. Samme med
lngden af felter. Pladsen er ligegyldig - harddiske er billige idag.
men man kan godt være interesseret i at enforce at noget ikke må være
længere end 20.

Tak for hjælpen gutter.

Har brugt en Int

Jeg havde faktisk en intention om at skrive præcist det, arne_v, men jeg må have haft en kort hjernebløning da jeg skrev det, for det er ikke kommet på tryk :)

Jeg har vist endnu ikke oplevet at der var et krav om at begrænse antal records, men f.eks. på en håndholdt enhed kunne det jo godt være noget, som man ville gøre noget ud af.

God pointe ... ville ønske jeg selv havde husket at skrive den med :D