Como NO desarrollar un sistema de información - Parte III

Ahora nos toca hablar de la base de datos, esa misteriosa capa de la aplicación que contiene la lógica del negocio (sí, ya sé que no tiene sentido) y además guarda la información que es necesaria para el funcionamiento del sistema.


La base de datos guarda toda la información del sistema en tablas, y lo normal es que las tablas estén relacionadas unas con otras mediante el uso de claves foráneas, pero la sintaxis para la cración de una clave foránea es demasiado complicada, y eso añade demasiadas validaciones al momento de hacer una inserción, que si el registro en la tabla referenciada no existe, que no se puede eliminar un registro porque la referencia todavía existe, que las actualizaciones no se pueden hacer porque violas las restricciones, etc., yo creo que lo mejor es olvidarnos de las claves foráneas y así simplificamos el diseño.

Lo siguiente es establecer las operaciones que se pueden hacer en el sistema, como siempre crear, editar, eliminar son obligatorias, pero la sintaxis SQL es demasiado complicada y el uso de un ORM es pensar demasiado una solucion que es bastante simple, vamos a usar stored procedures para TODO, los insert, update y delete los vamos a ejecutar dentro de unos stored procedure que se llamaran sp_ingreso, sp_modificacion y sp_eliminacion respectivamente, es más, podemos obviar el uso de updates porque es una operación atómica y las operaciones atómicas suenan complicadas, en vez de eso al momento de hacer una modificación en un registro existente, simplemente lo eliminamos y lo volvemos a insertar con los nuevos datos. Para simplificarle las cosas aqui les dejo el código:

CREATE STORED PROCEDURE sp_modificacion (id,dato1, dato2, dato3, ... , datoN)
BEGIN
exec sp_eliminacion id;
exec sp_insertar id,dato1, dato2, dato3, ... , datoN
END

Se ve facil y además es facil de recordar.

Otra cosa es recordar que 70% de la lógica del negocio se almacena en la base de datos (repito, sé que no tiene sentido), y ¿adivinen qué? lo haremos con stored procedures, porque se puede ahorrar código en PHP o .NET usando IF, WHILE y FORs en SQL, además no nos precupamos por la validación de datos ni nada de eso, el servidor de base de datos se encargará de todo eso.

Y si en algún momento necesitamos crear nuevas funcionalidades o nuevas operaciones, simplemente podemos crear un stored procedure que cree nuevos stored procedures que cumplan con los nuevos requerimientos, así tendríamos un sistema que genera código para sí mismo pero sin complicar el código fuente, eso si es algo digno de un genio.

Continuará.... (en algún momento supongo que terminaré)