Consideraciones previas antes de diseñar una base de datos.

Leí una definición de base de datos que me gusta y viene a decir más o menos que

Una base es un reflejo de una parte de una realidad que queremos administrar

1. Relatividad de las bases.

La definición anterior es algo que no debemos olvidar nunca por varios motivos:

Al ser un reflejo depende del color del cristal con que lo miremos.

Al ser de una parte, aunque estemos hablando de lo mismo, de un taller, cada uno podemos tomar una parte, yo querré controlar el almacén y tu no, etc.

Como es lo que queremos administrar, cada uno podemos administrar lo mismo de formas distintas, por ejemplo tu administras el almacén y yo no, tu solo cobras al contado y yo cobro al contado y crédito, etc.

Con lo anterior quiero hacer ver que cada uno podemos tener necesidades distintas y por tanto la solución que uno adopte puede ser válida para el pero no para otro.

Imaginemos que estamos hablando de reparaciones o trabajos que realizamos a vehículos, en ese caso tu puedes indicar que la clave principal del vehículo es la matricula, pero en mi caso puede que todos los coches estén sin matricular y por tanto tu propuesta no me sirve.

Con esto no quiero desanimarte, solo quiero indicar que a la hora de consultar/plantear algo, hay que dar todos los detalles posibles, y aun así de las respuestas que nos den, lo que tenemos que hacer es entenderlas e intentar adaptarlas a nuestra realidad.

1. Que debemos hacer y que no hacer en una base

Otro tema es el de las cosas que se deben y no se deben hacer en una base, esta claro que hay cosas en las que todos estamos mas o menos de acuerdo, no se debe guardar un campo calculado, no se debe repetir un dato, etc. pero teniendo claro lo que hacemos y porque, y sobre todo sus ventajas e inconvenientes podemos hacer lo que nos plazca y tampoco hay que ser estrictos 100%.

A la pregunta de donde guardar un precio para no duplicarlo, mi opinión es que si tenemos una tabla de productos en los que tenemos los precios, a la hora de hacer una factura es conveniente/necesario no solo guardar el Producto, si no que también tenemos que guardar el precio aunque parezca que estamos repitiendo un dato y que lo podemos coger de la tabla productos.

En mi opinión hay que guardar el precio en la tabla facturas (mejor en la tabla DetallesFacturas) por varios motivos, uno que aun cliente concreto podemos querer cobrarle otro precio, y otro motivo es que cuando cambiemos los precios en la tabla productos, si no tenemos guardado el precio en la factura todas las facturas tomaran el precio actual cosa que no es cierto para las facturas antiguas.

Podemos considerar que el precio en la tabla productos es PrecioActual y que el precio en la factura es PrecioCobrado, de esta forma no tenemos datos repetidos porque son conceptos distintos.

2. Tiempo de validez de una base, eliminar datos, versatilidad de los datos.

Otro punto que considero importante a la hora de diseñar una base de datos es el periodo de tiempo en el que queremos que nuestra base sea válida.

Si hacemos una base de datos en la que tengamos vehículos y propietarios de alguna forma tendremos que relacionar vehículos y personas.

Si consideramos que un vehículo solo puede tener un propietario al mismo tiempo y montamos nuestra base con ese criterio, la base solo tendrá validez para un momento puntual.

Si queremos guardar un histórico de los distintos propietarios de un vehículo tendremos que poder relacionar un vehículo con mas de una persona y por tanto tenemos que montar nuestra base para que eso sea posible.

Si continuamos con el ejemplo de vehículos y propietarios, es posible pensar que cuando un vehículo se dé de baja lo borramos de nuestra base de datos y listo.

En general mi criterio es NO borrar datos de nuestra base, si hemos creado un vehículo y al final no hemos gestionado nada de ese vehículo o lo hemos creado por error si podríamos modificar sus datos o eliminarlo, ahora bien, si hemos gestionado algo del vehículo mi criterio es no borrarlo aunque el vehículo se haya dado de baja y ya no lo vayamos a gestionar mas.

Motivos hay varios, uno que si lo borramos perderemos el histórico y eso es una parte importante de nuestra base.

En lugar de eliminar algo que no vamos a gestionar yo prefiero marcarlo como no válido, dado de baja, obsoleto o como queramos llamarle.

Una vez que hemos decidido no borrar podemos pensar en agregar un campo en el cual indicar si el elemento en cuestión es vigente o no, ahora bien, aquí viene lo de la versatilidad de los datos guardados.

Hay que intentar hacer lo máximo posible con los menos datos que podamos, continuando con el supuesto anterior, en lugar de poner ese campo donde indicar si algo esta dado de baja o no, yo pondría un campo donde guardar la fecha en que algo se da de baja.

Si hacemos esto, podemos saber fácilmente que elementos son vigentes o no en funciona que tengan fecha de baja o no, y además tendremos oto dato que nos puede servir y que es la fecha en que algo se ha dado de baja.

3. Por ultimo están los ‘Yaques’:

Ya que tenemos este informe porque no hacemos otro que nos muestre…..,

Ya que estamos porque no dejamos que el usuario seleccione……

A ser posible hay que anticiparse a lo que nos puedan pedir en un futuro para la base y a ser posible dejarla preparada para ello, por ejemplo para llevar el almacén aunque ahora no lo hagan, para permitir varias modalidades de pago aunque ahora solo usemos, una, etc.