Barrapunto

MySql ha apostado desde el principio por sacrificar la funcionalidad en aras de conseguir mayores prestaciones y solidez. Examinando la comparativa, se puede deducir que, afortunadamente, sigue haciéndolo.

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.
Es decir, en un entorno de producción que necesite una gestión de datos sin muchas complicaciones funcionales, pero con fuertes requerimientos de concurrencia y velocidad ( y me atrevería a decir que son la mayoría ), es mas eficaz - más "profesional" - un gestor que sacrifique la funcionalidad para obtener un mayor rendimiento.
Por el contrario, si existe un desarrollo activo de la "lógica de los datos" ( entendiendo por tal todo el aparato lógico que puede desarrollarse dentro del gestor de BBDD, como triggers, constraints, procedimientos almacenados, funciones integradas, funciones de usuario, tipos de datos de usuario, etc. etc. ) es cuando se necesita un gestor de BBDD que te ofrezca dichas funcionalidades, aunque su rendimiento sea menor.

Puedo estar equivocado, pero en mi opinión, la mayoría de los gestores de BBDD instalados se encuentran en la primera situación. Es decir, la mayoría de los Oracles y DB2 que andan funcionando por ahí, están sirviendo a una o dos aplicaciones ( o un conjunto integrado de ellas como maxi/mini ERP's ), en las que es importante el rendimiento, mientras que sus potentes funcionalidades, incluidas las posibilidades de Orientación a Objeto, no se usan en absoluto.
En esas circunstancias, sería conceptualmente acertado recomendar el uso de un gestor de BBDD como MySql. Digo conceptualmente, porque la mayoría de los paquetes de gestión te imponen su gestor de BBDD, o como mucho, te dejan escoger entre dos o tres, que son los de siempre, y entre los cuales no se suelen encontrar los gestores de BBDD 'Open Source'.
Pero eso no quita, para poder mantener la opinión de que, en la mayoría de los entornos de producción, sería más "profesional" un gestor como MySql que un Oracle, un DB2 o un SQL Server. Por supuesto que la gran mayoría de los gerentes, o de las personas que aprueban los presupuestos de compras de los departamentos de Sistemas, opinan exactamente lo contrario, pero las razones en que se suelen basar no acostumbran a tener fundamentos muy racionales.
Lo que es más triste, es que hay muchos profesionales de Tecnologías de la Información, que opinan exactamente lo mismo que ellos, y con razones de parecido fundamento.

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)