mySQL primaire veld als integer?

[Gertjan Groen]

Hoi,

In mySQL zie je dat het eerste veld met id meestal als "int not null primary
key" is gedefinieerd. Dit neem ik dan ook vaak over. Maar is het niet een
beetje overdreven overgedimensioneerd? Daar zijn waarden van -2.147.483.648
t/m 2.147.483.647 mogelijk. En waarom zou je een signed waarde kiezen, als
de waarde toch altijd groter dan 0 is? Terwijl in de rest van het database
ontwerp vaak erg kritisch naar ieder bitje wordt gekeken (b.v. nemen we niet
beter een char(8) dan een varchar(255)?) Of is er een speciale reden voor?

Zou je niet beter een smallint of mediumint kunnen nemen als key? Met
smallint kun je nog altijd (unsigned) 65.535 waarden in je db stoppen.

Groeten,
Gertjan

[Stefan Koopmanschap (remove withoutspam to e-mail)]

Gertjan Groen wrote:
> In mySQL zie je dat het eerste veld met id meestal als "int not null primary
> key" is gedefinieerd. Dit neem ik dan ook vaak over. Maar is het niet een
> beetje overdreven overgedimensioneerd? Daar zijn waarden van -2.147.483.648
> t/m 2.147.483.647 mogelijk. En waarom zou je een signed waarde kiezen, als
> de waarde toch altijd groter dan 0 is? Terwijl in de rest van het database
> ontwerp vaak erg kritisch naar ieder bitje wordt gekeken (b.v. nemen we niet
> beter een char(8) dan een varchar(255)?) Of is er een speciale reden voor?

volgens mij, maar iemand moet me verbeteren als het niet zo is, kan een
char of varchar niet auto_increment hebben...

>
> Zou je niet beter een smallint of mediumint kunnen nemen als key? Met
> smallint kun je nog altijd (unsigned) 65.535 waarden in je db stoppen.

daar heb je gelijk in, als je er van uit gaat dat je nooit meer dan
65535 waarden in je db zal hebben. vergeet niet dat wanneer een record
wordt gedelete, de id's nog steeds auto_incrementen bovenop de hoogste
id, en de id die gedelete is niet vrij komt. dus kan het best zijn dan
als een database lang in gebruik is en er veel mee gebeurt, je toch
vroeger of later op 65.535 komt voor je id, waarna het dan mis kan gaan.

Het is dus vooral vooruit kijken. waar heb je de tabel voor nodig,
hoeveel wordt ie gebruikt, en hoe lang wordt je huidige applicatie
waarschijnlijk gebruikt.


--
Stefan Koopmanschap
PHP/MySQL developer - websites, intranet and extranet systems and more...
http://www.stefankoopmanschap.com/
php@stefankoopmanschap.com

[Rene Pijlman]

Gertjan Groen:
>In mySQL zie je dat het eerste veld met id meestal als "int not null primary
>key" is gedefinieerd. Dit neem ik dan ook vaak over. Maar is het niet een
>beetje overdreven overgedimensioneerd? Daar zijn waarden van -2.147.483.648
>t/m 2.147.483.647 mogelijk.

In het geheugen van een fatsoenlijk hedendaagse computer kun je een getal
in de orde van 2^(8*512*2^20) kwijt, dus waarom zou je de waarden in
hemelsnaam tot dat soort speelgoedgetalletjes beperken? Je beperkt je
files toch ook niet tot 2 KByte?

>En waarom zou je een signed waarde kiezen, als de waarde toch altijd groter
>dan 0 is?

Omdat dat de natuurlijke representatie is in de meeste onderliggende
architecturen (lees: hardware).

>Terwijl in de rest van het database ontwerp vaak erg kritisch naar ieder
>bitje wordt gekeken (b.v. nemen we niet beter een char(8) dan een
>varchar(255)?)

Dat is bij de meeste database engines en toepassingen volkomen onnodig.
Wie dat "vaak" doet, doet waarschijnlijk iets verkeerd.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Inca]

Rene Pijlman wrote:
> In het geheugen van een fatsoenlijk hedendaagse computer kun je een
> getal in de orde van 2^(8*512*2^20) kwijt, dus waarom zou je de
> waarden in hemelsnaam tot dat soort speelgoedgetalletjes beperken? Je
> beperkt je files toch ook niet tot 2 KByte?

In dat geval vraag ik me af waarom er nog zoveel types zijn (tinyint,
mediumint, longtext, text etc)

Kunnen we die dan ook niet beter afschaffen?
--
Inca

[Stefan Koopmanschap (remove withoutspam to e-mail)]

Inca wrote:
> Rene Pijlman wrote:
>
>>In het geheugen van een fatsoenlijk hedendaagse computer kun je een
>>getal in de orde van 2^(8*512*2^20) kwijt, dus waarom zou je de
>>waarden in hemelsnaam tot dat soort speelgoedgetalletjes beperken? Je
>>beperkt je files toch ook niet tot 2 KByte?
>
>
> In dat geval vraag ik me af waarom er nog zoveel types zijn (tinyint,
> mediumint, longtext, text etc)
>
> Kunnen we die dan ook niet beter afschaffen?

dat hangt natuurlijk helemaal af van de waardes die erin komen. het is
efficienter als je zeker weet dat je int toch niet groter als een
bepaald maximum wordt om een kleiner type te gebruiken. voor een primary
key is het echter misschien verstandig om een groot veldtype te nemen
omdat je nooit weet hoe lang je systeem mee gaat

--
Stefan Koopmanschap
PHP/MySQL developer - websites, intranet and extranet systems and more...
http://www.stefankoopmanschap.com/
php@stefankoopmanschap.com

[Rene Pijlman]

Inca:
>Rene Pijlman:
>> In het geheugen van een fatsoenlijk hedendaagse computer kun je een
>> getal in de orde van 2^(8*512*2^20) kwijt, dus waarom zou je de
>> waarden in hemelsnaam tot dat soort speelgoedgetalletjes beperken? Je
>> beperkt je files toch ook niet tot 2 KByte?
>
>In dat geval vraag ik me af waarom er nog zoveel types zijn (tinyint,
>mediumint, [...]
>
>Kunnen we die dan ook niet beter afschaffen?

Volgens mij bestaan die nog voornamelijk vanwege terugwaartse
compatibiliteit met database-systemen uit de oertijd, toen dit soort
dingen nog wel ter zake deden. En bij hele grote databases kan het
misschien wat ruimte besparen.

[QOOO]
>longtext, text etc)

Dat is een ander verhaal, omdat op de 'gewone' 'kleine' string-datatypen
allerlei operatoren en functionaliteit ondersteund wordt, die bij de
'long' en/of 'large' varianten niet beschikbaar is. Denk aan indexeren,
opnemen in PK/FK's, < en >, order by etc.

Maar een smallint biedt niet meer mogelijkheden dan een gewone integer.
Het enige verschil is
1) het waardenbereik, dat je conceptueel beter met een semantisch zinnige
constraint kunt inperken i.p.v. met de arbitraire limieten van het
datatype, en:
2) opslagruimte in de database (dit verschilt natuurlijk per
database-type)

En bij de meeste alledaagse applicaties speelt de opslagruimte van de
integers geen rol van betekenis. Zeker niet bij web content management
systemen, die 99,99% tekst en blob's bevatten

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

In de relatief kleine databases maakt het inderdaad niet heel veel uit (qua
prestaties) wat voor types je kiest, maar als je het over tabellen hebt met
miljoenen records maakt het wel degelijk uit wat je uit kiest.

Evert

"Rene Pijlman" <reply.in.the.newsgroup@my.address.is.invalid> schreef in
bericht news:58rp201qcnn80llkjppm675l5vdtthn96o@4ax.com...
> Inca:
> >Rene Pijlman:
> >> In het geheugen van een fatsoenlijk hedendaagse computer kun je een
> >> getal in de orde van 2^(8*512*2^20) kwijt, dus waarom zou je de
> >> waarden in hemelsnaam tot dat soort speelgoedgetalletjes beperken? Je
> >> beperkt je files toch ook niet tot 2 KByte?
> >
> >In dat geval vraag ik me af waarom er nog zoveel types zijn (tinyint,
> >mediumint, [...]
> >
> >Kunnen we die dan ook niet beter afschaffen?
>
> Volgens mij bestaan die nog voornamelijk vanwege terugwaartse
> compatibiliteit met database-systemen uit de oertijd, toen dit soort
> dingen nog wel ter zake deden. En bij hele grote databases kan het
> misschien wat ruimte besparen.
>
> [QOOO]
> >longtext, text etc)
>
> Dat is een ander verhaal, omdat op de 'gewone' 'kleine' string-datatypen
> allerlei operatoren en functionaliteit ondersteund wordt, die bij de
> 'long' en/of 'large' varianten niet beschikbaar is. Denk aan indexeren,
> opnemen in PK/FK's, < en >, order by etc.
>
> Maar een smallint biedt niet meer mogelijkheden dan een gewone integer.
> Het enige verschil is
> 1) het waardenbereik, dat je conceptueel beter met een semantisch zinnige
> constraint kunt inperken i.p.v. met de arbitraire limieten van het
> datatype, en:
> 2) opslagruimte in de database (dit verschilt natuurlijk per
> database-type)
>
> En bij de meeste alledaagse applicaties speelt de opslagruimte van de
> integers geen rol van betekenis. Zeker niet bij web content management
> systemen, die 99,99% tekst en blob's bevatten
>
> --
> René Pijlman
>
> Wat wil jij leren? http://www.leren.nl

[Rene Pijlman]

Stefan Koopmanschap (remove withoutspam to e-mail):
>het is efficienter als je zeker weet dat je int toch niet groter als een
>bepaald maximum wordt om een kleiner type te gebruiken.

Ik vind het niet altijd efficiënter.

Ik heb laatst bij de beherende partij een e-mail adres aangevraagd, dat ik
vervolgens in het CMS van de ontwikkelpartij wilde invoeren. Helaas was
ons adres 51 tekens lang, terwijl de ontwikkelaar een arbitraire limiet
van 50 tekens had ingebouwd. Je wilt niet weten hoeveel ITIL-procedures en
OTAP-straten ik heb moeten doorlopen en hoeveel declarabele uren er
besteed zijn om dit op te lossen.

Ban de arbitraire limieten uit! Leve de grenzeloze getallen die we op de
lagere school hebben geleerd.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Inca]

Rene Pijlman wrote:
>> longtext, text etc)
>
> Dat is een ander verhaal, omdat op de 'gewone' 'kleine'
> string-datatypen allerlei operatoren en functionaliteit ondersteund
> wordt, die bij de 'long' en/of 'large' varianten niet beschikbaar is.

Hmm, dat geldt wel voor het verschil varchar/char vs text maar niet voor
text, longtext etc, toch?
Geen van de text-types hebben die mogelijkheden toch?
--
Inca

[Rene Pijlman]

Inca:
>Rene Pijlman:
>>> longtext, text etc)
>>
>> Dat is een ander verhaal, omdat op de 'gewone' 'kleine'
>> string-datatypen allerlei operatoren en functionaliteit ondersteund
>> wordt, die bij de 'long' en/of 'large' varianten niet beschikbaar is.
>
>Hmm, dat geldt wel voor het verschil varchar/char vs text maar niet voor
>text, longtext etc, toch?
>Geen van de text-types hebben die mogelijkheden toch?

Specifiek MySQL bedoel je zeker, OK zou kunnen. Ik had het meer in zijn
algemeenheid over het onderscheid tussen 'kleine' functionele en 'grote'
alleen-opslag strings bij verschillende databases.

Het enige verschil dat ik kan ontdekken tussen text en longtext bij MySQL
is 2 bytes opslagruimte. Nou, wat een feest, de harddisk-fabrikanten
bibberen en beven van het omzetverlies dat ze zullen lijden.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl