Разлике између VARCHAR и INTEGER поља у кључевима

Користим целобројне ID-ове као примарне кључеве у својим табелама. Шта ако бих уместо тога користио varchar поља? Хоћу ли изгубити на перформансама у том случају, посебно за велике табеле? Хоће ли спајања (joins) и даље радити једнако брзо као за целобројну колону.

Ваше перформансе би требало да буду приближно исте са varchar или integer типовима. Firebird увек пореди кључеве индекса бајт по бајт и чува се само значајни део вредности.

Кључ са једним пољем се прво конвертује у један од три канонска типа: стринг са колацијом, double precision и (нажалост) 64-битни цео број. Датуми постају double precision бројеви са покретном тачком.

Стрингови који имају колацију различиту од њихове бајтне вредности конвертују се у формат колације. То је помало црна магија и повећава величину стринга, али резултат је да стринг проналази своје исправно место када се сортира са другим стринговима исте колације. ‘A’, ‘a’, ‘â’, ‘á’, ‘Ă’, ‘ã’, ‘ä’, ‘å’, ‘ă’, ‘ą’, ‘Ā’ се сви појављују на својим предвиђеним местима. (Извините због онога што је ово урадило вашем имејл клијенту… у мом, то је једанаест варијанти слова ‘A’.) Завршне празнине нису укључене у кључ.

Double precision број се трансформише тако да се и он сортира бајт по бајт - отприлике инвертује се знак, затим експонент, па мантиса, уз скраћивање завршних нула.

У зависности од ендијанства 64-битних целих бројева на рачунару, и они се трансформишу тако да се пореде бајт по бајт. То можда делује као лоша оптимизација, али кључеви индекса се не чувају на природним границама и подлежу префиксној компресији, тако да не постоји начин да се користи веће поређење од бајт по бајт.

Сложени кључеви су углавном исти. Сваки део се конвертује у свој тип кључа индекса и допуњава се до вишеструког броја од 4 бајта. Након свака четири бајта, Firebird додаје бајт са позицијом тренутног поља кључа. Тако би индекс на LastName, FirstName, ZodiacSign изгледао као 1Harr1ison2Ann 3Gemi3ni. Ово избегава непријатност мешања Damnation са Dam nation.

Зашто сам горе рекао “(нажалост)”? Зато што постојање јединственог формата за бројеве омогућава Firebird-у да промени величину бројева без поновног креирања индекса на њима. Али када је Borland вратио 64-битне целе бројеве - InterBase је имао 64-битне целе бројеве од почетка на Vax рачунарима - неки бистар ум је схватио да double precision има 56 бита прецизности, а 64-битни цели бројеви имају 64 бита. С друге стране, Firebird индекси су дизајнирани да поднесу извесну непрецизност… или се преосталих 8 бита може додати на крај… шта год. Дакле, морате поново изградити индексе када прелазите са Numeric/Decimal 9 на Numeric/Decimal 12. Тужно.

“Префиксна компресија?” Приликом чувања кључа који није први на страници или први након скока на страници, Firebird гледа претходни кључ и скраћује онај део почетка следећег кључа који је дупликат свог претходника, те додаје дужину скраћеног дела на почетак. Тако стрингови “AAAA”, “AAAB”, “AAAC”, “AABC” постају

“AAAA”, “3B”, “3C” и “2BC”. Постоји проблем са неким форматима GUID-ова који стављају променљиви део броја прво, а затим фиксни део. То онемогућава префиксну компресију и повећава величину индекса.

“Скок?” - Префиксна компресија значајно смањује величину индекса, смањујући I/O, али захтева читање целе странице да би се дешифровао кључ. То је у реду са страницама од 1K, али са већим величинама страница прорачун је био неприхватљив. Зато свака страница индекса сада има сопствени индекс који показује на офсете некомпримованих уноса. Тај индекс се назива вектор скока.

Ann Harrision