Rozdíly mezi poli VARCHAR a INTEGER v klíčích

Používám celočíselné ID jako primární klíče ve svých tabulkách. Co kdybych místo toho použil varchar pole? Ztratím v tom případě výkon, zejména u velkých tabulek? Budou joiny fungovat stejně rychle jako u celočíselného sloupce?

Váš výkon by měl být přibližně stejný s varchary i celými čísly. Firebird vždy porovnává klíče indexů bajtově a ukládá pouze významnou část hodnoty.

Jednopolní klíč je nejprve převeden na jeden ze tří kanonických typů: řetězec s kolací, double precision a (bohužel) 64bitové celé číslo. Data se stávají čísly s plovoucí desetinnou čárkou double precision.

Řetězce, které mají jinou kolaci než svou bajtovou hodnotu, jsou převedeny do svého kolacioního formátu. To je něco jako černá magie a rozšiřuje velikost řetězce, ale výsledkem je, že řetězec najde své správné místo při řazení s jinými řetězci stejné kolace. ‘A’, ‘a’, ‘â’, ‘á’, ‘Ă’, ‘ã’, ‘ä’, ‘å’, ‘ă’, ‘ą’, ‘Ā’ se všechny objeví na svých určených místech. (Omlouvám se za to, co to udělalo s vaším e-mailovým klientem …. v mém je to jedenáct variant ‘A’.) Koncové mezery nejsou do klíče zahrnuty.

Číslo double precision je upraveno tak, aby se také řadilo bajtově - zhruba invertovat znaménko, pak exponent, pak mantisu, s oříznutím koncových nul.

V závislosti na endianitě 64bitových celých čísel v počítači jsou i ta upravena tak, aby se porovnávala bajtově. To se může zdát jako nevýhoda, ale klíče indexů nejsou ukládány na přirozených hranicích a procházejí prefixovou kompresí, takže není možné použít větší porovnání než bajt po bajtu.

Složené klíče jsou velmi podobné. Každá část je převedena na svůj typ indexového klíče a doplněna na násobek 4 bajtů. Po každých čtyřech bajtech Firebird přidá bajt s pozicí aktuálního pole klíče. Takže index na LastName, FirstName, ZodiacSign by vypadal jako 1Harr1ison2Ann 3Gemi3ni. To zabraňuje trapnosti záměny Damnation s Dam nation.

Proč jsem výše řekl “(bohužel)”? Protože mít jednotný formát pro čísla umožňuje Firebirdu měnit velikost čísel bez přetváření indexů na nich. Ale když Borland přidal zpět 64bitová celá čísla - InterBase měl 64bitová celá čísla od začátku na Vaxech - nějaký bystrý duch si všiml, že double precision má 56 bitů přesnosti a 64bitová celá čísla mají 64 bitů. Na druhou stranu jsou indexy Firebirdu navrženy tak, aby zvládly určitou nepřesnost … nebo zbývajících 8 bitů mohlo být přidáno na konec … cokoliv. Takže musíte přestavět indexy při přechodu z Numeric/Decimal 9 na Numeric/Decimal 12. Smutné.

“Prefixová komprese?” Při ukládání klíče, který není první na stránce nebo první po skoku na stránce, se Firebird podívá na předchozí klíč a zkrátí tu část začátku dalšího klíče, která duplikuje svého předchůdce, a na začátek přidá délku zkrácené části. Takže řetězce “AAAA”, “AAAB”, “AAAC”, “AABC” se stanou

“AAAA”, “3B”, “3C” a “2BC”. Existuje problém s některými formáty GUID, které dávají volatilní část čísla první, následovanou pevnou částí. To maří prefixovou kompresi a zvětšuje velikost indexů.

“Skok?” - Prefixová komprese výrazně zmenšuje velikost indexů, snižuje I/O, ale vyžaduje čtení přes celou stránku k rozluštění klíče. To je v pořádku s 1K stránkami, ale s většími velikostmi stránek byl výpočet nepřijatelný. Takže každá stránka indexu má nyní svůj vlastní index ukazující na offsety nekomprimovaných záznamů. Tento index se nazývá skokový vektor.

Ann Harrision