Malas prácticas en el diseño de bases de datos: ¿Estás cometiendo estos errores?

Cada vez que a usted, como desarrollador, se le asigna una tarea basada en un código existente, debe enfrentar muchos desafíos. Uno de esos desafíos, la mayoría de las veces el más exigente, implica comprender el modelo de datos de una aplicación.

Normalmente se enfrenta a tablas, vistas, columnas, valores, procedimientos almacenados, funciones, restricciones y disparadores confusos que tardan mucho en tener sentido para usted. Y, una vez que lo hacen, empiezas a notar muchas formas de mejorar y aprovechar la información almacenada.

Si es un desarrollador experimentado, es probable que también note cosas que podrían haberse hecho mejor al principio, es decir, fallas de diseño.

En este artículo, aprenderá sobre algunas de las malas prácticas comunes de diseño de bases de datos, por qué son malas y cómo puede evitarlas.

Mala Práctica No. 1: Ignorar el Propósito de los Datos

Los datos se almacenan para ser consumidos más tarde, y el objetivo siempre es almacenarlos y recuperarlos de la manera más eficiente. Para lograr esto, el diseñador de la base de datos debe saber de antemano qué van a representar los datos, cómo se van a adquirir y a qué velocidad, cuál será su volumen operativo (es decir, cuántos datos se esperan) y, finalmente, , cómo se va a utilizar.

Por ejemplo, un sistema de información industrial donde los datos se recopilan manualmente todos los días no tendrá el mismo modelo de datos que un sistema industrial donde la información se genera en tiempo real. ¿Por qué? Porque es muy diferente manejar unos pocos cientos o miles de registros por mes en comparación con administrar millones de ellos en el mismo período. Los diseñadores deben hacer consideraciones especiales para mantener la eficiencia y la facilidad de uso de la base de datos, si los volúmenes de datos van a ser grandes.

Pero, por supuesto, el volumen de datos no es el único aspecto a considerar, ya que el propósito de los datos también afecta el nivel de normalización, la estructura de datos, el tamaño del registro y la implementación general de todo el sistema.

Por lo tanto, conocer a fondo el propósito del sistema de datos que creará conduce a consideraciones en la elección del motor de la base de datos, las entidades a diseñar, el tamaño y formato del registro y las políticas de administración del motor de la base de datos.

Ignorar estos objetivos conducirá a diseños defectuosos en sus aspectos básicos, aunque estructural y matemáticamente correctos.

Mala práctica n.º 2: mala normalización

Diseñar una base de datos no es una tarea determinista; dos diseñadores de bases de datos pueden seguir todas las reglas y principios de normalización para un problema determinado y, en la mayoría de los casos, generarán diferentes diseños de datos. Esto es inherente a la naturaleza creativa de la ingeniería de software. Sin embargo, existen algunas técnicas de análisis que tienen sentido en todos los casos, y seguirlas es la mejor manera de llegar a una base de datos que funcione de la mejor manera.

A pesar de ello, muchas veces nos encontramos ante bases de datos diseñadas sobre la marcha sin seguir las reglas más básicas de normalización. Tenemos que ser claros al respecto: cada base de datos debe, al menos, normalizarse a la tercera forma normal, ya que es el diseño que mejor representará sus entidades, y cuyo rendimiento se equilibrará mejor entre consultas e inserción-actualización-eliminación de registros. .

Si tropieza con tablas que no cumplen con 3NF, 2NF o incluso 1NF, considere rediseñar estas tablas. El esfuerzo que inviertas en hacerlo te dará sus frutos a muy corto plazo.

Mala Práctica No. 3: Redundancia

Muy relacionado con el punto anterior, ya que uno de los objetivos de la normalización es reducirlo, la redundancia es otra mala práctica que aparece con bastante frecuencia.

Los campos y tablas redundantes son una pesadilla para los desarrolladores, ya que requieren lógica comercial para mantener actualizadas muchas versiones de la misma información. Esta es una sobrecarga que se puede evitar si las reglas de normalización se siguen a fondo. Aunque a veces la redundancia puede parecer necesaria, debe usarse solo en casos muy específicos y estar claramente documentada para que se tenga en cuenta en desarrollos futuros.

Los efectos negativos típicos de la redundancia son un aumento innecesario del tamaño de la base de datos, los datos son propensos a la inconsistencia y la disminución de la eficiencia de la base de datos, pero, lo que es más importante, puede conducir a la corrupción de los datos.

Mala Práctica No. 4: Mala Integridad Referencial (Restricciones)

La integridad referencial es una de las herramientas más valiosas que proporcionan los motores de bases de datos para mantener la mejor calidad de los datos. Si no se implementan restricciones o se implementan muy pocas restricciones desde la etapa de diseño, la integridad de los datos tendrá que depender completamente de la lógica comercial, lo que los hará susceptibles a errores humanos.

Mala práctica n.º 5: no aprovechar las funciones del motor de base de datos

Cuando utiliza un motor de base de datos (DBE), tiene una pieza de software poderosa para sus tareas de manejo de datos que simplificará el desarrollo de software y garantizará que la información sea siempre correcta, segura y utilizable. Un DBE proporciona servicios como:

• Vistas que brindan una forma rápida y eficiente de ver sus datos, generalmente desnormalizándolos para fines de consulta sin perder la exactitud de los datos.
• Índices que ayudan a acelerar las consultas en las tablas.
• Agrega funciones que ayudan a analizar la información sin necesidad de programar.
• Transacciones o bloques de sentencias que modifican datos que se ejecutan y comprometen o cancelan (revierten) si ocurre algo inesperado, manteniendo así la información en un estado perpetuo correcto.
• Bloqueos que mantienen los datos seguros y correctos mientras se ejecutan las transacciones.
• Procedimientos almacenados que proporcionan funciones de programación para permitir tareas complejas de gestión de datos.
• Funciones que permiten cálculos sofisticados y transformaciones de datos.
• Restricciones que ayudan a garantizar la corrección de los datos y evitar errores.
• Disparadores que ayudan a automatizar acciones cuando ocurren eventos en los datos.
• Optimizador de comandos (planificador de ejecución) que se ejecuta bajo el capó, asegurando que cada oración se ejecute de la mejor manera y manteniendo los planes de ejecución para futuras ocasiones. Esta es una de las mejores razones para usar vistas, procedimientos almacenados y funciones, ya que sus planes de ejecución se mantienen permanentemente en el DBE.

No conocer o ignorar estas capacidades llevará el desarrollo a un camino extremadamente incierto y seguramente a errores y problemas futuros.

Mala práctica n.º 6: claves primarias compuestas

Este es un punto controvertido, ya que muchos diseñadores de bases de datos hablan hoy en día sobre el uso de un campo autogenerado de ID entero como clave principal en lugar de uno compuesto definido por la combinación de dos o más campos. Esto se define actualmente como la "mejor práctica" y, personalmente, tiendo a estar de acuerdo con ella.

Sin embargo, esto es solo una convención y, por supuesto, los DBE permiten la definición de claves primarias compuestas, que muchos diseñadores consideran inevitables. Por lo tanto, al igual que con la redundancia, las claves primarias compuestas son una decisión de diseño.

Sin embargo, tenga cuidado, si se espera que su tabla con una clave principal compuesta tenga millones de filas, el índice que controla la clave compuesta puede crecer hasta un punto en el que el rendimiento de la operación CRUD se degrada mucho. En ese caso, es mucho mejor usar una clave principal de ID de entero simple cuyo índice sea lo suficientemente compacto y establezca las restricciones DBE necesarias para mantener la unicidad.

Mala práctica n.º 7: mala indexación

A veces, tendrá una tabla que necesitará consultar por muchas columnas. A medida que crece la tabla, notará que los SELECT en estas columnas se ralentizan. Si la tabla es lo suficientemente grande, pensará, lógicamente, en crear un índice en cada columna que use para acceder a esta tabla solo para encontrar casi de inmediato que el rendimiento de SELECT mejora pero INSERT, UPDATE y DELETE disminuyen. Esto, por supuesto, se debe al hecho de que los índices deben mantenerse sincronizados con la tabla, lo que significa una sobrecarga enorme para el DBE. Este es un caso típico de sobre indexación que puedes solucionar de muchas formas; por ejemplo, tener solo un índice en todas las columnas diferente de la clave principal que usa para consultar la tabla, ordenar estas columnas de la más usada a la menos puede ofrecer un mejor rendimiento en todas las operaciones CRUD que un índice por columna.

Por otro lado, tener una tabla sin índice en las columnas que se utilizan para consultarla, como todos sabemos, dará lugar a un rendimiento deficiente en las SELECT.

Además, la eficiencia del índice depende a veces del tipo de columna; los índices en columnas INT muestran el mejor rendimiento posible, pero los índices en VARCHAR, DATE o DECIMAL (si alguna vez tiene sentido) no son tan eficientes. Esta consideración puede incluso llevar a rediseñar tablas a las que se debe acceder con la mayor eficiencia posible.

Por lo tanto, la indexación siempre es una decisión delicada, ya que demasiada indexación puede ser tan mala como muy poca y porque el tipo de datos de las columnas a indexar tiene una gran influencia en el resultado final.

Mala práctica n.º 8: Convenciones de nomenclatura deficientes

Esto es algo con lo que los programadores siempre luchan cuando se enfrentan a una base de datos existente: comprender qué información se almacena en ella por los nombres de tablas y columnas porque, a menudo, no hay otra manera.

El nombre de la tabla debe describir qué entidad contiene, y cada nombre de columna debe describir qué información representa. Esto es fácil, pero empieza a complicarse cuando las tablas tienen que relacionarse entre sí. Los nombres comienzan a volverse desordenados y, peor aún, si existen convenciones de nomenclatura confusas con normas ilógicas (como, por ejemplo, "el nombre de la columna debe tener 8 caracteres o menos"). La consecuencia final es que la base de datos se vuelve ilegible.

Por lo tanto, una convención de nomenclatura siempre es necesaria si se espera que la base de datos dure y evolucione con la aplicación que admite, y aquí hay algunas pautas para establecer una concisa, simple y legible:

• No hay limitaciones en el tamaño del nombre de la tabla o columna. Es mejor tener un nombre descriptivo que un acrónimo que nadie recuerda o entiende.
• Los nombres que son iguales tienen el mismo significado. Evite tener campos que tengan el mismo nombre pero con diferentes tipos o significados; esto será confuso tarde o temprano.
• A menos que sea necesario, no sea redundante. Por ejemplo, en la tabla "Artículo", no es necesario tener columnas como "Nombre del artículo", "Precio del artículo" o nombres similares; "Nombre" y "Precio" son suficientes.
• Tenga cuidado con las palabras reservadas de DBE. Si una columna se va a llamar "Índice", que es una palabra reservada de SQL, intente usar una diferente como "Número de índice".
• Si se apega a la regla de la clave principal simple (un solo entero generado automáticamente), asígnele el nombre "Id" en cada tabla.
• Si se une a otra tabla, defina la clave foránea necesaria como un número entero, denominado "Id" seguido del nombre de la tabla unida (p. ej., IdItem).
• Si nombra restricciones, use un prefijo que describa la restricción (p. ej., "PK" o "FK"), seguido del nombre de la tabla o tablas involucradas. Por supuesto, el uso de guiones bajos ("_") con moderación ayuda a que las cosas sean más legibles.
• Para nombrar índices, utilice el prefijo “IDX” seguido del nombre de la tabla y la columna o columnas del índice. Además, use "ÚNICO" como prefijo o sufijo si el índice es único y guiones bajos cuando sea necesario.

Hay muchas pautas de nombres de bases de datos en Internet que arrojarán más luz sobre este aspecto tan importante del diseño de bases de datos, pero con estos básicos, al menos puede obtener una base de datos legible. Lo importante aquí no es el tamaño o la complejidad de sus pautas de nombres, ¡sino su consistencia al seguirlas!

Algunas observaciones finales

El diseño de bases de datos es una combinación de conocimiento y experiencia; La industria del software ha evolucionado mucho desde sus inicios. Afortunadamente, hay suficiente conocimiento disponible para ayudar a los diseñadores de bases de datos a lograr los mejores resultados.

Hay buenas pautas de diseño de bases de datos en Internet, así como malas prácticas y cosas que se deben evitar en el diseño de bases de datos. Solo elige tu elección y apégate a ella.

Y no lo olvides, solo a través de la experimentación, los errores y los éxitos aprendes, así que adelante y comienza ahora.