Las diferencias entre los campos VARCHAR e INTEGER en las claves

Estoy usando IDs enteros como claves primarias en mis tablas. ¿Qué pasaría si usara campos varchar en su lugar? ¿Perderé rendimiento en ese caso, especialmente para tablas grandes? ¿Las uniones seguirán funcionando tan rápido como lo hacen con la columna entera?

Tu rendimiento debería ser aproximadamente el mismo con varchars o enteros. Firebird siempre compara las claves de índice byte a byte y solo se almacena la parte significativa del valor.

Una clave de campo único se convierte primero a uno de los tres tipos canónicos: cadena con cotejamiento, doble precisión y (lamentablemente) entero de 64 bits. Las fechas se convierten en números de punto flotante de doble precisión.

Las cadenas que tienen un cotejamiento distinto a su valor de byte se convierten a su formato de cotejamiento. Eso es algo así como un arte oscuro y expande el tamaño de la cadena, pero el resultado es que la cadena encuentra su lugar correcto cuando se ordena con otras cadenas del mismo cotejamiento. ‘A’, ‘a’, ‘â’, ‘á’, ‘Ă’, ‘ã’, ‘ä’, ‘å’, ‘ă’, ‘ą’, ‘Ā’ aparecen todos en sus lugares designados. (Perdón por lo que eso le hizo a tu cliente de correo… en el mío, son once variantes de ‘A’.) Los espacios finales no se incluyen en la clave.

El número de doble precisión se modifica para que también se ordene byte a byte: aproximadamente se invierte el signo, luego el exponente, luego la mantisa, truncando los ceros finales.

Dependiendo del endianness de los enteros de 64 bits en la computadora, también se modifican para que se comparen byte a byte. Eso puede parecer una desoptimización, pero las claves de índice no se almacenan en límites naturales y sufren compresión de prefijo, por lo que no hay forma de usar una comparación más grande que byte por byte.

Las claves compuestas son muy similares. Cada parte se convierte a su tipo de clave de índice y se rellena a un múltiplo de 4 bytes. Después de cada cuatro bytes, Firebird agrega un byte con la posición del campo actual de la clave. Así, un índice en Apellido, Nombre, SignoZodiacal resultaría como 1Harr1ison2Ann 3Gemi3ni. Esto evita la vergüenza de confundir Damnation con Dam nation.

¿Por qué dije “(lamentablemente)” arriba? Porque tener un formato único para números permite a Firebird cambiar el tamaño de los números sin recrear los índices sobre ellos. Pero cuando Borland agregó los enteros de 64 bits de nuevo - InterBase tenía enteros de 64 bits desde el principio en las VAX - algún genio brillante se dio cuenta de que la doble precisión tiene 56 bits de precisión y los enteros de 64 bits tienen 64 bits. Por otro lado, los índices de Firebird están diseñados para manejar cierta imprecisión… o los 8 bits restantes podrían añadirse al final… lo que sea. Así que tienes que reconstruir los índices al pasar de Numeric/Decimal 9 a Numeric/Decimal 12. Triste.

“¿Compresión de prefijo?” Al almacenar una clave que no es la primera en una página o la primera después de un salto en la página, Firebird observa la clave precedente y trunca esa parte del inicio de la siguiente clave que duplica a su predecesora y añade la longitud de la parte truncada al principio. Así, las cadenas “AAAA”, “AAAB”, “AAAC”, “AABC” se convierten en

“AAAA”, “3B”, “3C” y “2BC”. Hay un problema con algunos formatos de GUID que colocan la parte volátil del número primero, seguida de la parte fija. Eso anula la compresión de prefijo e infla el tamaño de los índices.

“¿Salto?” - La compresión de prefijo reduce el tamaño de los índices en gran medida, reduciendo la E/S, pero requiere leer a través de toda la página para descifrar la clave. Está bien con páginas de 1K, pero con tamaños de página más grandes el cálculo era inaceptable. Así que cada página de índice ahora tiene un índice propio que apunta a los desplazamientos de las entradas sin comprimir. Ese índice se llama vector de salto.

Ann Harrision