Barrapunto

En un gestor de bases de datos están reñidos la funcionalidad y el rendimiento. Es fácil comprender que las transacciones serán más rápidas si no necesitan comprobar nigún "constraint", ni desencadenar ningún "trigger". Así mismo, será también más rápida una consulta si no existe "integridad referencial". Lo difícil es encontrar una buena síntesis entre funcionalidad y prestaciones, y la bondad de este compromiso depedenderá de la labor específica a la que esté orientado dicho gestor.

Y digo yo, ¿no sería posible que estuviesen disponibles la integridad referencial, triggers, ... y que se pudieran activar o desactivar en el momento de la compilación? De esta forma, si no necesitamos de estas características, al desactivarlas ganamos en velocidad, pero si las necesitamos recompilamos y ya está.

Yo tengo experiencia con PostgreSQL y solía utilizar integridad referencial, pero no utilizaba ni triggers ni procedimientos almacenados, así que desactivando estas opciones en tiempo de compilación podría obtener una mejora en el rendimiento.

De todas formas, no sé esa mejora de rendimiento sería tan significativa como para merecer la pena implemnetarla.

Pues yo me he pegado con Oracle bastante y te recomiendo que no pongas tanta fe en él, porque a mí también me han pasado cosas graciosísimas, tanto o más como la que tu cuentas.

Una puntualización, la versión 4 de MySQL, utilizando tablas de tipo InnoDB, sí que soporta transacciones "ACID" (al menos eso es lo que dice la web, yo no lo he llegado a probar)