Cuando se plantea un desarrollo a medida, una de las primeras preguntas que se hace es: ¿Qué base de datos se va a utilizar?
Aunque creáis que no, tomar la base de datos como un medio o como un fin, condiciona en gran medida el desarrollo del sistema.
Base de datos como Fin
Si consideramos que la base de datos es la parte más importante de la aplicación, nos preocuparemos de que los datos sean fácilmente legibles. En primer lugar diseñaremos un modelo de datos, que posteriormente se traducirá a clases.
La base de datos será el centro del negocio, otras aplicaciones podrían atacar directamente a nuestra base de datos.
Base de datos como Medio
Desde este punto de vista, la base de datos se considera como un mero sistema para persistir los objetos de negocio de nuestra aplicación
Son los objetos de nuestra aplicación los que realmente ofrecen valor, la consulta de datos de nuestro sistema se debe realizar mediante una capa de servicios que desarrollaremos nosotros, el acceso directo a base de datos podrías dar como resultado lecturas incorrectas.
Adaptaremos el modelo de datos a las necesidades de nuestro código, primando el diagrama de clases sobre modelando los datos.
En los últimos años, estamos asistiendo al proliferación de las bases de datos documentales. Esta movimiento se podría considerar como el punto extremo del uso de la base de datos como medio. Ya que de esta forma abandonamos toda la experiencia y el conocimiento que ya existe en las bases de datos relacionales, por un sistema menos estándar.
Lo cierto es que esta moda me recuerda a las bases de datos orientadas a objetos, de las que tanto se hablaba en los 90, mientras que hoy en día parece que nadie se acuerda de ellas.
Aunque personalmente considero las bases de datos como medio y no como fin, ¿por qué?
Los objetos son los que contienen la información relevante, los objetos no son nadie sin las reglas de negocio a aplicar, que las tengo en las clases, no en la base de datos (nada de procedimientos almacenados, funciones de base datos o trigers). Si alguien quiere acceder a mis datos que me lo pida a través de una capa de integración. Mis datos los toco yo, nadie más.
Eso no significa que no use características de las base de datos, quizás la más importante sea la transaccionalidad, delego en ella la generación de ids.
Aunque esta aproximación no siempre se puede aplicar, por ejemplo en grandes empresas con bases de datos enormes que alimentan a varias aplicaciones y con un departamento de administración de base de datos. Muchos consideran que trabajar con DBAs es un suplicio por las restricciones que imponen, pero en modelos realmente grandes, con millones de registros, que alguien conozca como se comporta la base de datos y que nos indique como diseñar las tablas para evitar problemas de rendimiento es una ventaja.
¿Y tu qué opinas? ¿Modelas primero la base de datos y en ella basas tus objetos? ¿Comienzas por el diagrama de clases? ¿o eres de los aventureros que se adentra en las bases de datos documentales?
Según mi experiencia, las aplicaciones se mueren, los datos perduran. ¿Cuántas veces te has comido un modelo de datos de mierda? Así que vale la pena hacer un buen diseño aunque penalice ligeramente los tiempos de desarrollo.
ResponderEliminarno creo que se hagan modelos tan difíciles de leer. Por ejemplo el uso de PKs sin significado de negocio. En el típico ejemplo de factura y detalle. Casi toda la gente de BD haría que detalle tuviese una PK compuesta por idDetalle e idFactura, pero lo recomendado por muchos ORMs es hacer que detalle tenga una PK única idDetalle e idFactura sea una FK.
ResponderEliminarPor otro lado el uso de PKs sin significado de negocio es para muchos DBAs con los que me he cruzado una mala práctica porque te obliga a mantener dos IDs. Mientras que desde mi punto de vista, las PKs deben de estar controladas por mí.
Por ejemplo: Estamos catalogando productos, tenemos categorías de productos, y los usuarios utilizan un codigo de 3 dígitos. Mucha gente te recomienda que eso sea la PK, de esta forma utilizando el codigo como filtro en otras tablas ya recuperas la información. Es decir que la información de la tabla a golpe de select es significativa.
Personalmente prefiero que ese código sea un campo y tener una PK interna.
¿Por qué? Tengo que mantener dos índices y las consultas sobre las tablas relacionadas con categorias no son lo suficientemente descriptivas, ya que necesito hacer un join con la maestra para tener información. PERO prefiero vivir eso a una migración de datos cuando me cambian el codigo de una categoría. Porque el cliente puede decir misa, al final, siempre te cambian los datos y se pueden montar pequeños desastres.
Típica pregunta en la que uno podría respoder algo diferente dependiendo del momento y del proyecto.
ResponderEliminarEn mi opinión... Idealmente, los datos debería ser la base de todo, deberían esta aislados y se deberían definir independientemente de como se persistan, de quien o de como se acceda a ellos y de lo que se pretenda hacer con ellos.
Una buena política de definición de datos de negocio y de su gestión y mantenimiento facilita la incorporación continúa de aplicaciones para su explotación.Además de favorecer integraciones ...
Al final, las aplicaciones que los procesan, muestran,agrupan, generan..., son entes que mutan, evolucionan, que son sustituidas unas por otras y no creo que debieran influir en su definición.
Además con la cantidad de frameworks que permiten esta abstracción e independizar los datos del resto de procesos, su consecución, no lo veo un problema.