Barrapunto

Los procedimientos almacenados, triggers, integridad referencial y transacciones cargan la responsabilidad de la integridad de la base de datos sobre el servidor, y liberan al cliente de dicho trabajo.

Esto, en general, es importantismo. El diseñador de la base de datos no necesita confiar en que el lado cliente haga las cosas bien, en general el servidor puede rechazar operaciones incorrectas. Sin embargo, tiene un precio: velocidad en las inserciones, modificaciones y borrado. Aunque no hagamos uso de estas características, si un gestor de base de datos las soporta, penaliza las modificaciones. Pureba a insertar 1000 registros en un MySQL de las primeras versiones y en un PostgreSQL sin utilziar triggers ni integrida referencia.... un abismo.

Yo no me atrevería a hacer un programa con datos sensibles sin las características avanzadas, especialmente una base de datos a la que el usuario puede tener acceso. Sin embargo, para una base de datos simple, en internet, donde sólo el programa que yo he hecho puede entrar, hay media docena de tablas, estoy dispuesto a renunciar a las características avanzadas (quizá, salvo transaciones) a cambio de velocidad.

Además, la verdad últimamente prefiero una arquitectura three-teer, (es decir, un servidor intermedio que recibe las peticiones del cliente y las manda a la base de datos) en lugar del clásico cliente/servidor. En el three-teer programas en el lenguaje que te da la gana, en lugar de en un lenguaje pobre y farragoso de SQL-XX. Y si a este cliente le quiero colocar un Interbase, al tro na un informix, y al de más allá un PostgreSQL, no tengo que reprogramar todos los procedimientos y triggers.

En resumen, hay dos tipos de bases de datos: a) Grandes, pesadas y fiables. b) Ligeras sin caracteristcas avanzadas y la fiabildiad en el cliente. No creo que MySQL haga bien en moverse de lo que era hasta ahora: Una base de datos ligera.