Buenas costumbres en el diseño de aplicaciones. Primera parte.

Una aplicación pensada para crecer y adaptarse al negocio.

Hoy en día vemos que los lenguajes de programación de frontend van cambiando mutando y pasando de moda, en contrapartida las bases de datos si bien se actualizan perduran en el tiempo. Y su lenguaje va evolucionando manteniendo compatibilidad con versiones anteriores.

Hablando en mi caso específicamente de dos de las bases comerciales mas usadas y sin desprecio del resto que existen. Me refiero a MSSQL y a Oracle.

Lo dicho anteriormente si bien para mi es una máxima, entiendo que cada uno tiene su librito, pero obviamente mi opinión esta basada en mi experiencia y en mis aproximados 25 años en el rubro. Pasando por múltiples plataformas de trabajo, muchas aplicaciones con distintos usos y pasando por entornos de trabajos muy dispares.

La justificación de mis opiniones viene después y podemos debatir, y hay muchos libritos diferentes, pero ahora pasare a dar lo que si son mis máximas para una aplicación sencilla solida y con la capacidad de crecer.

Estoy convencido que la solidez y sencillez de una aplicación empieza con su arquitectura, por lo cual elegiría una base de datos que me permitiera diseñar una arquitectura solida y que tenga herramientas que me permita mantener la integridad de la información sin pasarme horas programando y generando código para ello.

¿Ya por el párrafo anterior se vislumbra que para mí la base no solo será el contenedor de los datos y la que mantendrá la integridad de la información, sino que además colocare mi capa de negocio completa ahí y cuando digo completa me refiero a entera, y porque esto? Esto me permite lo siguiente que yo podría ir cambiando el frontend, o incluso tener multiples frontend y siempre el comportamiento seria el mismo. El frontend solo accedería a la capa de negocio y siempre tendría el mismo resultado. Solo dejaría del lado del frontend lo que tuviera que ver con la usabilidad de la aplicación, pero la misma ya existiría completamente dentro de la base de datos.

Esto yo lo encontré altamente beneficioso, porque los cambios de negocio me llevan a cambiar cosas en un solo lugar, y los cambios de tecnología que afectan sobre todo a los frontend (hoy la mayoría webs, .net., java , mobile, etc.) no afectan a mi aplicación la cual sigue existiendo independientemente.

Pero vamos por partes, primero la arquitectura de la información, y una primera decisión ¿mi base será una base de consulta, de transacciones o mixta? Usualmente las bases arrancan con uso mixto. Y esto puede ir cambiando en el tiempo y mutando, hacia un esquema de transacciones y a su vez una base de consulta desdoblándose así la información y hasta tornándose redundante en beneficio de la velocidad de acceso a la misma.

La información usualmente la divido en tablas como una unidad de información que tendrá un conjunto de datos de estructura igual y contenido similar.

En mi experiencia estos conjuntos de información a su vez se clasifican en tipos determinados y enumero a continuación tablas maestros, transaccionales, bitácoras.

Maestros: Tablas que contienen un conjunto de información finito que, si bien puede variar, no es común y su razón de existir es ser referido por otro conjunto de información una especie de lista de clasificación. Ejemplos una tabla de países, una tabla de sucursales, de tipos de estados, de productos, etc.

Transaccionales: están son las tablas donde registramos nuestras operaciones y usualmente en una aplicación son las que tienen mas movimiento diariamente, por adición de información y modificación de esta. Por ejemplo, en una empresa de seguros la tabla de pólizas donde ingresan las nuevas pólizas y se mantienen las existentes.

Bitácoras: Estas tablas en mi experiencia deben tener una estructura muy similar a la transaccional a la que referencia, pudiendo agregarse si no lo tuviera ya, momento en el tiempo en que ocurre el cambio y obviamente su id independiente al que se referencia hacia la transaccional. En mi opinión, estas tablas deben tener una concepción desde el principio de la creación de la arquitectura, ya que me permitirá saber en cualquier momento por mas que hoy no sea requerido, el estado exacto de un conjunto de datos en un momento preciso en el tiempo. Esto nos ahorrará miles de dolores de cabeza, ya que el mismo usuario que hoy te dirá que no requiere esto, el día de mañana te dirá quiero saber qué valor tenía esta póliza en marzo del 2016 y podremos responderle. Estas bitácoras deberán extenderse a las tablas Maestros para obtener todo el universo. Otra solución es tener el dato completo desnormalizado pero ya llegaremos a eso.

·        Buenas prácticas, todas las tablas deben tener su id.

·        Toda relación debe estar referenciada con su primary y foreing key correspondiente siempre y bajo ningún concepto obviarlo.

·        La base siempre es la mejor opción para llevar el conteo de los ids, nunca usar código para hacerlo.

·        La mejor opción para poblar la bitácora es usar un trigger donde le diremos que ante un insert /update o delete copie el registro en la bitácora adicionando la fecha del cambio, con esto siempre tendremos una foto al día.

·        Se debe armar un diccionario de funciones donde detallar parámetros que recibe y a que objetos de la base afecta haciendo que insertando borrando updateando, este material es de consulta y alimentación constante durante el desarrollo de esta manera evitamos duplicar código.

·        Toda solución debe ser sencilla, de tornarse muy compleja deberá dividirse en soluciones mas pequeñas y sencillas que puedan ser reutilizados por otros procesos.

·        Cada tabla nueva debe crearse con su propio proceso de insert, update y delete, con las validaciones particulares de cada una.

·        Si una validación se usara muchas veces, deberá ser una función de validación única que pueda ser llamada cada vez que se necesite.

·        Es buena costumbre tener en cada tabla un campo con la fecha de actualización del registro y registrado quien realizo el cambio.

·        El diccionario de datos y el de funciones debe poder generar una tabla de doble entrada donde se identifique donde se cruzan, esto el día de mañana nos permite tener una idea clara de la magnitud de un cambio o nueva funcionalidad.

·        Una tabla nunca tiene campos demás siempre los necesarios cualquier cambio en la estructura genera nuevos campos nunca borra campos.