Database Systems Labs
Que exige la norma, que añade cada producto y como se escribe código que sobrevive a un cambio de motor.
4 clases · 12 horas · 15 conceptos · 12 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
SQL no es un lenguaje, son varios que se parecen. Esta parte separa lo que exige la norma ISO/IEC 9075 de lo que cada producto añade por su cuenta, y produce un artefacto revisable en lugar de una intención: una matriz que registra, construcción por construcción, si es de norma y cómo la escribe cada motor del proyecto.
Después de la matriz vienen tres estudios de caso elegidos por contraste. PostgreSQL, como ejemplo de motor extensible que absorbe familias enteras —vectores, geometría, series— sin dejar de ser relacional. El bloque MySQL, MariaDB, SQL Server y Oracle, centrado exclusivamente en las divergencias que rompen código: modo estricto, cadena vacía tratada como nulo, plegado de identificadores. Y los dos motores embebidos, SQLite y DuckDB, cuya comparación deja ver el efecto del formato de almacenamiento con la menor cantidad posible de ruido operativo.
El objetivo no es ser portable a toda costa. Es saber, línea a línea, cuándo estás atando el proyecto a un producto —lo que muchas veces es la decisión correcta— y cuándo lo estás haciendo sin darte cuenta.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 030 | Portabilidad: qué exige la norma y qué añade cada motor | Intermedio | 3 | 4 |
| 031 | PostgreSQL: tipos, extensiones y modelo de procesos | Intermedio | 3 | 3 |
| 032 | MySQL, MariaDB, SQL Server y Oracle: divergencias que rompen código | Intermedio | 3 | 4 |
| 033 | SQLite y DuckDB: motores embebidos, transaccional frente a analítico | Intermedio | 3 | 3 |
Qué exige la norma ISO/IEC 9075 y qué añade cada producto por su cuenta. El resultado de la clase no es una opinión sobre portabilidad sino un artefacto: una matriz que registra, construcción por construcción, si es de norma y cómo la escribe cada motor del proyecto.
norma frente a producto matriz de portabilidad extensión propietaria
PostgreSQL como caso de estudio de motor extensible: tipos compuestos, arreglos, rangos y JSONB de fábrica, extensiones que añaden vectores o geometría sin tocar el núcleo, y un modelo de proceso por conexión que explica por qué el agrupador de conexiones deja de ser opcional. Incluye autovacuum, que reaparece en la parte 08.
extensión tipo compuesto proceso por conexión autovacuum
Las divergencias concretas que rompen código al cambiar de motor: el modo estricto de MySQL que convierte datos inválidos en silencio, la cadena vacía que Oracle trata como nulo, y el plegado de mayúsculas de los identificadores sin citar. Cada una se demuestra con el `INSERT` que en un motor falla y en otro «funciona».
colación modo estricto cadena vacia frente a nulo identificador citado
Los dos motores embebidos del programa y por qué no compiten entre sí: SQLite es transaccional y por filas, DuckDB es analítico, columnar y vectorizado. La comparación deja ver, con la menor cantidad posible de ruido operativo, cómo el formato de almacenamiento decide el perfil de rendimiento.
motor embebido tipado dinamico almacenamiento columnar vectorización
Cada uno de estos es una creencia habitual y su corrección.
Los 15 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| almacenamiento columnar | Guardar juntos todos los valores de una misma columna en lugar de todas las columnas de una misma fila. Una consulta analítica lee solo las columnas que necesita y comprime mucho mejor, porque los valores contiguos se parecen entre sí. | 033 |
| autovacuum | Proceso que recupera el espacio de las versiones de fila muertas que deja MVCC y actualiza las estadísticas del planificador. Cuando se queda atrás, la tabla se hincha y los planes se degradan: dos síntomas que se ven antes en el monitor que en el error. | 031 |
| cadena vacia frente a nulo | Divergencia que rompe código al migrar: Oracle trata la cadena vacía `''` como `NULL`, y el resto de motores la distingue. Una condición `= ''` cambia de significado según el producto, y un `NOT NULL` deja de proteger lo que se creía. | 032 |
| colación | El conjunto de reglas que decide cómo se comparan y ordenan los textos: si `a` = `A`, dónde va la `ñ`, si los acentos cuentan. Cambia el resultado de `ORDER BY`, de `=` y de un `UNIQUE`, y es distinta por defecto en cada motor. | 032 |
| extensión | Módulo cargable que añade tipos, operadores, índices o funciones a PostgreSQL sin tocar su núcleo: `pgvector`, `PostGIS`, `pg_stat_statements`. Es el mecanismo por el que un motor relacional cubre familias enteras —vectores, geometría, series— sin dejar de ser el mismo motor. | 031 |
| extensión propietaria | Sintaxis o función que solo existe en un motor: `LIMIT` frente a `FETCH FIRST`, `ON CONFLICT` frente a `MERGE`, tipos de arreglo, `RETURNING`. Usarlas es legítimo y a menudo correcto; lo que no lo es, es usarlas sin saber que se está atando el proyecto a ese producto. | 030 |
| identificador citado | Nombre de objeto entre comillas dobles —o entre acentos graves en MySQL, entre corchetes en SQL Server—. Al citarlo se vuelve sensible a mayúsculas y se congela tal cual; sin citar, cada motor lo pliega a un caso distinto, y ahí nacen los «la tabla no existe» al cambiar de producto. | 032 |
| matriz de portabilidad | Tabla que registra, para cada construcción usada, si es de norma y cómo la escribe cada motor del proyecto. Convierte la portabilidad en un artefacto revisable en lugar de en una intención declarada en la primera reunión. | 030 |
| modo estricto | Ajuste que decide si el motor rechaza un dato inválido o lo convierte en silencio. MySQL sin modo estricto trunca cadenas y transforma fechas imposibles en ceros; el mismo `INSERT` que en PostgreSQL falla, allí «funciona» y corrompe. | 032 |
| motor embebido | Base de datos que corre dentro del proceso de la aplicación, sin servidor ni puerto: SQLite, DuckDB. Elimina el costo de operación y la latencia de red, a cambio de no poder servir a varias máquinas. | 033 |
| norma frente a producto | La distinción entre lo que exige ISO/IEC 9075 y lo que cada motor añade por su cuenta. Ningún producto implementa la norma entera y todos la extienden; saber en qué lado está cada línea de tu código es lo que decide si una migración de motor cuesta un día o un trimestre. | 030 |
| proceso por conexión | Modelo de PostgreSQL: cada conexión es un proceso del sistema operativo con su propia memoria. Es robusto —una caída no arrastra a las demás— y caro: por eso un agrupador de conexiones deja de ser un lujo a partir de unos cientos de clientes. | 031 |
| tipado dinamico | En SQLite el tipo pertenece al valor, no a la columna: la declaración es una sugerencia (afinidad) y no una barrera. Cómodo para prototipar, peligroso para datos que otro sistema leerá; desde la versión 3.37 existen las tablas `STRICT` para recuperar el rigor. | 033 |
| tipo compuesto | Tipo de dato definido por el usuario con varios campos, o los tipos estructurados que PostgreSQL trae de fábrica: arreglos, rangos, `JSONB`, tipos enumerados. Permiten modelar sin salir del relacional lo que en otros motores obligaría a una tabla más o a un documento. | 031 |
| vectorización | Procesar lotes de miles de valores por llamada en lugar de una fila cada vez. Amortiza el costo de interpretación del plan y aprovecha las instrucciones SIMD del procesador; es la segunda mitad —junto al formato columnar— de la ventaja analítica de DuckDB o ClickHouse. | 033 |
12 obras distintas sostienen lo que se afirma en estas 4 clases.