El tener una buena estructura en nuestra base de datos es imprescindible no sólo por orden, sino también para reducir el peso de la misma así como poder brindar mejores reportes (con más detalles autocalculables por ejemplo). Ah, y la rápidez con que se hagan las consultas también dependerá de ello.
Aunque el tener una sola tabla donde acumular ciertos registros que luego puedan ser agrupados para mostrar resumenes o concentrados de la misma puede llegar a ser tentador, no en todos los casos es viable.
Un ejemplo sería el sólo contar con una tabla para registros de facturas donde se ingresan todos los artículos de dicha factura y cuando se quiere ver en forma de concentrado (por folio) sólo se agrupasen los registros. El error en este tipo de tablas y usos es que pueden llegarse a repetir datos en ciertos campos de forma innecesaria (como el número de folio, nombre del cliente, RFC, etc.), provocando el incremento en el peso de nuestra base de datos.
Una solución a esto es contar con 2 tablas interrelacionadas donde la primera sólo sea un control del ID de la factura con detalles como folio, fecha, cliente, RFC, etc. Y la segunda tabla con los registros de los artículos y precios de los mismos.
De esta forma evitamos repetir los datos de RFC, cliente, fecha y otros, en el registro de cada artículo que constituye la factura. Esto sin mencionar que a veces se usa un campo para comentarios que suelen extenderse bastante.
Un consejo es que recuerden que múltiples tablas pueden accederse en una sola consulta mendiante el uso de left join, full join o consultas en formato ANSI. Por ello a veces es necesario manejar más de un índice único para cada registro en nuestras tablas.
No hay comentarios:
Publicar un comentario