junio 13, 2012

SAP HANA SQL para geeks con poco tiempo

by Gemma Durany

Episodio #1: La importancia de ser TINY. Tipos de datos y otros monstruos.

SAP HANA SQL no es en sí mismo muy complicado. Está fuertemente basado en el estándar SQL-92, con un par de extensiones aquí y allá.

Si tuviera que decidir cuál es mi tipo de dato primitivo preferido en SQL, sin dedicarle mucho más esfuerzo intelectual que el que ya le dediqué, elegiría el unsigned integer de 8 bits, porque es liviano, lindo, y lleva el no tan pequeño (pero sí pleonástico) nombre de "TINYINT" (por favor, nótese que uso comillas dobles para no identificadores)

Si hacen las cuentas, verán que 2 elevado a la 8 es 256. Esto significa que un TINYINT puedo adoptar valores entre 0 y 255, lo cual debería ser suficiente para columnas que tengan datos enteros, tales como la edad de una persona.

No me parece que durante los próximos cien o doscientos años vayamos a tener problemas de tipo Y2K con respecto a la longevidad humana. Quizá los niños que nacen hoy puedan vivir 100-110 años en promedio (aunque todavía no me convence esta extrapolación estadística). Aun así, creo que no voy a vivir mucho más que eso, o al menos no tanto como para ver una nueva era de olas de migración de software y hardware que ocurran espontáneamente. Sería interesante hacer un estudio estadístico global (quizá ya haya más de uno) y calcular el porcentaje de desarrolladores que se preocupan por analizar cuidadosamente la cantidad mínima/máxima de almacenamiento que hace falta para los diferentes campos de datos de una aplicación de software.

Mi hipótesis es que muchos desarrolladores tienden a elegir tipos de datos ligeramente "sobredimensionados", por las dudas. Yo misma solía hacer eso hace unos años, cuando realmente trabajaba como desarrolladora, pero bueno... no era una brillante Wozniak. También tengo que admitir que hace diez o quince años era lo suficientemente ingenua como para pensar que el Club de Roma estaba exagerando un poco en 1972.

Durante la prehistoria IT, había que ahorrar espacio de almacenamiento a la fuerza. Hoy en día, la gente piensa que puede darse el lujo de derrochar cantidades desorbitantes de RAM y CPU, porque la "capacidad aumenta y los precios bajan" todo el tiempo.

No hace falta ser extremadamente inteligente en cuanto a temas ecológicos como para ver la trampa en este razonamiento, a pesar de que nos bombardeen con este tipo de afirmaciones todo el tiempo.

Vuelvo ahora por un momento al pensamiento puramente robótico, aunque todavía tengo más para decir sobre el tópico anterior y voy a seguir desarrollando esta línea argumentativa en el futuro próximo.

Presento aquí un breve resumen de los principales tipos de datos en SAP HANA SQL, por pura (¿y robótica?) diversión:

Para fecha y hora los ganadores son:

DATE (desde 0001-01-01 hasta 9999-12-31)
TIME (HH24-MI-SS)
SECONDDATE (0001-01-01 00:00:01 hasta 9999-12-31 24:00:00)
TIMESTAMP (0001-01-01 00:00:00.0000000 hasta 9999-12-31 23:59:59.9999999)

Para tipos numéricos, empezamos con...

TINYINT (entero de 8 bits sin signo)
continuamos con SMALLINT (entero de 16 bits con signo)
INTEGER (entero de 32 bits con signo)
BIGINT (entero de 64 bits con signo)
DECIMAL (precisión entre 1 y 34, escala entre -6000+ y +6000+). Ejemplo: 31416 x 10-4 tiene precisión 5 y escala 4.
SMALLDECIMAL (decimal de punto flotante; sólo tiene soporte para almacenamiento orientado a columnas, con precisión de hasta 16 y escala de 369 aprox.)
REAL (punto flotante de 32 bits)
DOUBLE (punto flotante de 64 bits)
y por último FLOAT(n), un REAL de 32 ó 64 bits, con n bits significativos hasta 53. Steve Jobs no se hubiera imaginado tal variedad de tipos de punto flotante hace más de veinte años. ¡Una verdadera orgía!

Para cadenas de caracteres tenemos lo siguiente:

VARCHAR(n) para caracteres ASCII characters, con n hasta 5000
NVARCHAR(n) para caracteres del set Unicode
y ALPHANUM(n) con una longitud máxima n de 127 (mucho menor que la de VARCHAR). Mi memoria me está engañando, porque creo ver aquí un tipo "CHAR" de longitud no variable. En otras versiones de SQL hay siempre al menos un CHAR, pero no lo encuentro en la documentación de SAP HANA. Dado que mi competencia en el manejo de SQL es en la actualidad como mi francés, es decir, no demasiado malo pero no siempre fluido, a menos que lo use en la práctica durante dos semanas seguidas, no podría decir con seguridad por qué quitaron CHAR, si es que en realidad lo quitaron. La causa debe residir en alguna cuestión de eficiencia, para bien o para mal.

Tenemos VARBINARY(n) para tipos binarios.
Y por cierto también tenemos tipos Objeto Grande (Large Object, LOB) como...
BLOB para datos binarios grandes
CLOB para datos ASCII
y NCLOB para datos Unicode. No todo se puede hacer con LOBs: por ejemplo, no se permite ORDER BY, ni GROUP BY, así como tampoco usarlos como PRIMARY KEY. En verdad, no usaría un video de YouTube como PRIMARY KEY, aunque pudiera; pero podría llegar a cambiar de opinión, como los sabios suelen hacer.

Por mi parte, eso es todo con respecto a los tipos de datos SAP HANA SQL... Y acá termino. Tengo que recrear unos usuarios en una instancia SAP HANA que voy a usar mañana para el próximo training; después voy a crear un par de variables para unas Vistas Analíticas, para poder alardear un poco (aunque por ahora este asunto de las variables en SAP HANA Studio no brinda la mejor experiencia al usuario, para ponerlo en términos diplomáticos), y también quiero observar el comportamiento de los nuevos y majestuosos Privilegios Analíticos (sigilosamente, por supuesto, y sin cámaras). Por último, pero no por eso menos importante, tengo que preparar la comida... en colaboración. Me dio hambre después de tanto hablar de recursos y almacenamiento, pero nos gusta la cocina mediterránea, que tiende a ser más magra que las demás.

Gemma Durany
Co-Fundadora
Glooobal GmbH



No hay comentarios:

Publicar un comentario