[KarlRoos]

Jag har tänkt på en sak, när man sätter fältlängder på kolumner i databaser så har jag i alla fall fått för mig att man ska sätta längden på 8 , 16, 32, 64, 128, 256...

Finns det någon fördel med att göra detta mot att sätta "mänskliga" tal?

[SimonP]

Jag gör det alltid av ren vana och ofta tjänar man på det, ett 32-bits OS jobbar ju med 4 bytes åt gången.

[martine]

Originally posted by KarlRoos@Feb 15 2009, 13:06
Jag har tänkt på en sak, när man sätter fältlängder på kolumner i databaser så har jag i alla fall fått för mig att man ska sätta längden på 8 , 16, 32, 64, 128, 256...

Finns det någon fördel med att göra detta mot att sätta "mänskliga" tal?

Jag misstänker att detta spelar alltmindre roll med tiden. För en processor som jobbar med 64 bitar betyder 8-bitars fält att dessa behöver maskas ut ur en 64-bit vilket till och med skulle kunna ta längre tid (men behöva mindre plats) än 64 bitar. Att maska ut t.ex. 10 bitar är inte så särskilt mycket mer komplicerat. Allt detta går dock väldigt snabbt nuförtiden.

Detsamma gäller strängar - förut kunde man kanske vara lite effektivare med 8-bitarsblock men nu med utf-8 och andra fler-bytes-teckenkodningar så finns det ingen nytta med att deklarera dessa i potenser av 2 eftersom platsen ett tecken tar inte längre stämmer överens med ett bestämt antal bitar. (En sträng med 8 tecken kunde tidigare "lyftas" med 2 operationer av en 32-bitarsprocessor men med utf-8 så finns det inget som säger att ett tecken behöver just 8 bits.) Eventuellt skulle det kunna ge en prestandavinst att ha fälten i databasen i ucs-2 (dvs. ren unicode) som alltid tar 16 bitar - här skulle det kunna tänkas att processorn snabbare skulle kunna bearbeta större textmassor snabbare - men det måste ju för det mesta ändå konverteras och levereras i utf-8 vilket äter upp en eventuell prestandavinst.

Lägg dessutom till att databaserna lägger till extra bytes och bits för null-värdet och strängterminering och liknande och det hela blir långt ifrån säkert att det lönar sig att använda just 16 eller 32 osv.

För att få ett riktigt bra svar på din fråga bör du nog specificera vilken databas och processorstruktur du använder och i synnerhet vilka datatyper du avser. Men risken är nog att det inte längre ger några vidare prestandavinster - och i så fall får du nog belastningstesta databasen själv…

Bra databasstruktur och ordentlig indexering är betydligt viktigare.

[tartareandesire]

I 99% av fallen spelar det nog som martine skriver extremt liten roll. Har man extrem trafik och / eller extrema datamängder så finns det dock all anledning till att effektivisera in i minsta detalj men då är nog som sagt var det enda rätta att köra egna belastningstester och denna detalj är då trots allt långt ifrån den viktigaste.

[studiox]

Originally posted by KarlRoos@Feb 15 2009, 13:06
Jag har tänkt på en sak, när man sätter fältlängder på kolumner i databaser så har jag i alla fall fått för mig att man ska sätta längden på 8 , 16, 32, 64, 128, 256...
Finns det någon fördel med att göra detta mot att sätta mänskliga tal?

Det beror på vad du ska lagra. En CHAR så spelar det inte så stor betydelse. en INT spelar det större betydelse.