Malas Prácticas en el Diseño de la Base de Datos: ¿Estás Cometiendo estos Errores?

by Fernando Martinez - Freelance Software Engineer @ Toptal (translated by Marisela Ordaz)

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

Normalmente te enfrentas a tablas, vistas, columnas, valores, procedimientos almacenados, funciones, restricciones y desencadenantes confusos que tardan mucho tiempo en tener sentido para ti. Y una vez que lo tienen, comienzas a notar muchas maneras de mejorar y aprovechar la información almacenada.

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



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

Mala Práctica N° 1: Ignorar el Propósito de la Data

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é representarán los datos, cómo se va a adquirir y a qué velocidad, cuál será su volumen operativo (es decir, cuántos datos se esperan) y, finalmente, cómo se usará.

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 cientos o miles de registros por mes en comparación con gestionar millones de ellos en el mismo período. Los diseñadores deben tener consideraciones especiales para mantener la eficiencia y la usabilidad 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 sobre 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 sean correctos estructural y matemáticamente.

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, hay algunas técnicas de análisis que tienen sentido en cada instancia y seguirlas es la mejor manera de acceder a una base de datos que rinde al máximo.



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

Si te encuentras con tablas que no cumplen con 3NF, 2NF, o hasta 1NF, considera rediseñar estas tablas. El esfuerzo que inviertas para hacerlo valdrá la pena en muy corto plazo.

Mala Práctica N° 3: Redundancia

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

Los campos y tablas redundantes son una pesadilla para los desarrolladores ya que requieren lógica de negocios para mantener actualizada gran parte de la misma información. Esto es una sobrecarga que puede evitarse si las reglas de normalización se siguen al pie de la letra. Aunque a veces puede parecer necesaria la redundancia, debe utilizarse sólo en casos muy específicos y debe estar claramente documentada para poder tenerse en cuenta en futuros desarrollos.

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 disminuye la eficiencia de la base de datos pero—más importante—podría llevar a una corrupción en la data.

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

La integridad referencial es una de las herramientas más valiosas que proporcionan los motores de base de datos para mantener la calidad de los datos en su mejor forma. Si no se implementan restricciones o muy pocas restricciones desde la etapa de diseño, la integridad de los datos tendrá que depender totalmente de la lógica de negocios, lo que la hace susceptible a errores humanos.

Mala Práctica N° 5: No Aprovechar las Características del Motor de Base de Datos

Cuando estás usando un motor de base de datos, tienes una poderosa pieza de software para tus tareas de manejo de datos que simplificará el desarrollo del software y garantizará que la información sea siempre correcta, segura y utilizable. Un Motor de Base de Datos proporciona servicios como:

• Vistas que proporcionan una manera rápida y eficiente de ver tus datos, por lo general desincronizándolos para fines de consulta sin perder la corrección de los datos.
  
• Índices que ayudan a acelerar las consultas en las tablas.
  
• Funciones agregadas que ayudan a analizar información sin programación.
  
• Transacciones o bloques de oraciones que alteran los datos que se ejecutan y comprometen o cancelan (retrotraen) si ocurre algo inesperado, manteniendo así la información en un estado permanentemente 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 administración de datos.
  
• Funciones que permiten cálculos sofisticados y transformaciones de datos.
  
• Restricciones que ayudan a garantizar la exactitud de los datos y evitar errores.
  
• Disparadores que ayudan a automatizar las acciones cuando ocurren eventos en los datos.
  
• Comando optimizador (planificador de ejecución) que se ejecuta bajo el capó, asegurando que cada frase se ejecuta en su mejor momento y manteniendo los planes de ejecución para futuras ocasiones. Ésta 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 Motor de Base de Datos.
  
  

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 de controversia ya que muchos diseñadores de bases de datos hablan hoy sobre el uso de un campo generado automáticamente como ID principal como la clave principal en lugar de un 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, el Motor de Base de Datos permite la definición de claves primarias compuestas, que muchos diseñadores piensan que son inevitables. Por lo tanto, al igual que con la redundancia, las claves primarias compuestas son una decisión de diseño.

Sin embargo, ten en cuenta que si esperas que tu tabla con una clave primaria 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 está muy degradado. En ese caso, es mucho mejor usar una clave primaria ID simple que tenga un índice lo suficientemente compacto y establezca las restricciones de

Motor de Bases de Datos necesarias para mantener la singularidad.

Mala Práctica N° 7: Mala Indexación

A veces tendrás una tabla que necesitas consultar por muchas columnas. A medida que la mesa crezca, notarás que los SELECT en estas columnas se ralentizan. Si la tabla es lo suficientemente grande, pensarás lógicamente, en crear un índice en cada columna que uses para acceder a esta tabla pero notarás casi de inmediato que el rendimiento de los SELECT mejora, pero INSERT, UPDATE y DELETE caen. Esto por supuesto se debe al hecho de que los índices deben mantenerse sincronizados con la tabla, lo que significa una sobrecarga masiva para el Motor de Base de Datos. Este es un caso típico de indexación excesiva que puedes resolver de muchas maneras; por ejemplo, tener solo un índice en todas las columnas diferentes a la clave principal que utilizas para consultar la tabla, ordenar estas columnas de las más utilizadas a las menos puede ofrecer un mejor rendimiento en todas las operaciones de CRUD que un índice por columna.
Por otro lado, tener una tabla sin índice en las columnas que se utilizan para consultarlo conducirá, como todos sabemos, a un bajo rendimiento en SELECTs.
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 llega a tener sentido) no son tan eficientes. Esta consideración puede incluso llevar a rediseñar tablas a las que se debe acceder con la mejor eficiencia posible.
Por lo tanto, la indexación es siempre 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 Deficiente

Esto es algo con lo que los programadores siempre luchan cuando se enfrentan a una base de datos existente: entendiendo qué información está almacenada 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é parte de la información representa. Esto es fácil, pero comienza a ser complicado cuando las tablas tienen que relacionarse entre sí. Los nombres comienzan a ensuciarse y, lo que es peor, si hay convenciones de nombres 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 perdure y evolucione con la aplicación que apoya y aquí hay algunas pautas para establecer una versión concisa, simple y legible:

• Sin limitaciones en el tamaño del nombre de tabla o columna. Es mejor tener un nombre descriptivo que un acrónimo que nadie recuerde o entienda.
  
• Los nombres que son iguales tienen el mismo significado. Evita 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 seas redundante. Por ejemplo, en la tabla “Artículo”, no es necesario tener columnas como “Nombre del elemento”, “Precio del artículo” o nombres similares; “Nombre” y “Precio” son suficientes.
  
• Ten cuidado con las palabras reservadas para el Motor de Base de Datos. Si una columna debe llamarse “Índice”, que es una palabra reservada de SQL, intenta utilizar una diferente como “NúmeroÍndice.”
  
• Si se apega a la regla de la clave primaria simple (autogenerado único entero), asígnale el nombre “Id” en cada tabla.
  
• Si se une a otra tabla, define la clave foránea necesaria como un entero, llamado “Id” seguido del nombre de la tabla unida (ej., IdItem).
  
• Si se nombran restricciones, usa un prefijo que describa la restricción (por ejemplo, “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, usa el prefijo “IDX” seguido del nombre de la tabla y la columna o columnas del índice. Además, usa “ÚNICO” como prefijo o sufijo si el índice es único y subraya 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 la base de datos pero con estos pasos básicos, al menos puedes acceder a una base de datos legible. ¡Lo importante aquí no es el tamaño o la complejidad de las pautas de nomenclatura sino su coherencia al seguirlas!

Algunas Observaciones Finales

El diseño de la base 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 directrices en el diseño de base de datos en todo el internet, así como malas prácticas y cosas que evitar en el diseño de la base de datos. Solo elije y mantenlo.

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

https://www.toptal.com/database/malas-prácticas-en-el-diseño-de-la-base-de-datos-estás-cometiendo-estos-errores-/es