Consejos de Tecnología

9 de los errores mas comunes en un diseño de base de datos

Como diseñador de bases de datos, cuando se te asigna un proyecto de base de datos, puedes esperar encontrarte con un par de desafíos durante el proceso de diseño y después de que la base de datos se haya implementado en producción.

Algunos de estos problemas son inevitables y están fuera de tu control. Sin embargo, algunos de ellos se deben a la calidad del diseño de la base de datos.


Las decisiones que tomes en esta fase preliminar pueden tener un profundo impacto en el buen funcionamiento de la base de datos. Los siguientes son algunos de los errores más comunes en el diseño de bases de datos.

 

Pobre Pre-planificación

Si estás construyendo una casa, no contratarías a un contratista e inmediatamente le exigirías que empiecen a colocar los cimientos en una hora.

Eso sería cortejar el desastre. Como mínimo, deberás acordar los planes para casa y los planos. No es diferente cuando se trata del diseño de bases de datos.

Cuanto mejor sea la planificación, mejor será la calidad del diseño.

Una buena base de datos es el resultado de una cuidadosa previsión y no una agregación de ideas ad hoc.

Una mala planificación del diseño puede dar lugar a problemas estructurales que serían costosos de resolver una vez que la base de datos se haya implementado.

No siempre es posible anticipar todos los problemas con los que se encontrará una base de datos, pero la planificación garantiza que puedas reducirlos solo a aquellos que son realmente inevitables.

 


Falta de comprensión del propósito de los datos

Las bases de datos se crean para una amplia gama de propósitos. Desde pequeñas bases de datos que almacenan los datos personales de un individuo hasta bases de datos empresariales masivas que manejan grandes volúmenes de información.

El diseñador debe comprender el propósito de la base de datos para diseñarla de forma optima y que este alineada con estos objetivos.

Las preguntas críticas que se deben hacer incluyen la naturaleza de los datos, cómo se obtienen, con qué frecuencia se almacenan y piden, su volumen y qué aplicaciones los utilizarán.

Una base de datos donde los datos se ingresan manualmente al final del día hábil no prosperará bajo el mismo modelo de diseño que una base de datos industrial sofisticada donde los datos se capturan y almacenan automáticamente y en tiempo real.

La clave está en decidirse por un diseño que garantice la eficiencia, la facilidad de uso y la seguridad de los datos (consulta seguridad postgresql). Ignorar el propósito de los datos conducirá a un diseño que marque todas las casillas correctas pero que sea prácticamente erróneo.



Normalización inadecuada

El diseño de la base de datos no es un proceso rígidamente determinista. Dos desarrolladores podrían seguir las mismas reglas de diseño pero aun así terminar con diseños de datos completamente diferentes.

Eso es en gran parte debido al lugar inherente de la creatividad en cualquier proyecto de ingeniería de software.

Sin embargo, hay ciertos principios básicos de diseño que son vitales para garantizar que la base de datos funcione de manera óptima. Uno de estos principios es la normalización.

La normalización se refiere a las técnicas utilizadas para desagregar tablas en partes constituyentes.

Esto se realiza hasta que cada tabla represente una sola cosa, mientras que las columnas describen los atributos del elemento que representa la tabla.

La normalización es un concepto de computación antiguo y ha existido durante más de 3 décadas.

De hecho, SQL se creó principalmente para leer y manipular conjuntos de datos normalizados. Para comprender la normalización, sería útil observar cómo funciona SQL.

SQL es un lenguaje intrínsecamente aditivo que está orientado a crear fácilmente un conjunto de resultados o valores.

Usando la sentencia FROM, puede extraer datos de una tabla y usar JOIN para agregarlos al contenido de otra tabla.

Puede trabajar con un número casi ilimitado de tablas para producir el tipo de datos que necesitas.

El poder aditivo de SQL es vital para el desarrollo y el rendimiento de la base de datos.

Los índices funcionan mejor cuando se pueden sincronizar con la clave primaria en su totalidad.

Cuando debe usar LIKE, CHARINDEX, SUBSTRING y comandos similares, para analizar un valor combinado con valores en una columna, el paradigma de SQL comienza a desintegrarse y los datos son cada vez menos fáciles de buscar.

Por lo tanto, la normalización de la base de datos es fundamental para la facilidad de desarrollo y un alto rendimiento constante.

Sin embargo, hay niveles en cuanto a la normalización y llegan a existir bases de datos sobre normalizadas. Una buena normalización equilibra las demandas de inserción, actualización, consulta y eliminación de registros.

La mejor práctica más aceptada es que las bases de datos deben normalizarse como mínimo a la tercera forma normal (3NF).

Sin embargo, la cuarta (4NF) y la quinta (5NF) pueden ser muy útiles, son fáciles de entender y valdrán la pena el esfuerzo una vez que sepas cómo trabajar con ellas.

Registros redundantes

Las tablas y los campos redundantes son una pesadilla para los diseñadores y administradores de bases de datos.

Consumen los recursos del sistema para mantenerse seguros, actualizados y respaldados. Es posible que los registros redundantes no parezcan demasiado cuando solo se trata de una docena.

Pero en las grandes bases de datos donde los campos redundantes pueden ser miles o millones, las sobrecargas de recursos informáticos son sustanciales.

Aumentan innecesariamente el tamaño de la base de datos, lo que reduce la eficiencia y aumenta el riesgo de corrupción de datos.

Por supuesto, hay ocasiones en que la redundancia puede ser necesaria, pero esta debería ser la excepción y no la regla.

Incluso cuando permites la redundancia, las razones deben documentarse claramente para asegurar que los futuros administradores de bases de datos las eliminen cuando las razones ya no sean válidas.

 


Mala indexación

En ocasiones, es posible que un usuario o una aplicación necesiten consultar numerosas columnas de una tabla.

A medida que aumenta el número de registros en la tabla, el tiempo que demoran estas consultas aumentará constantemente.

Para acelerar las consultas y reducir el impacto del tamaño general de la tabla, es util indexar las columnas de la tabla para que las entradas en cada una estén disponibles de forma casi inmediata cuando se invoca una consulta SELECT.

Desafortunadamente, la aceleración de la sentencia SELECT generalmente produce una ralentización de la sentencias INSERT, UPDATE y DELETE.

Esto se debe en gran parte a que los índices tienen que estar constantemente sincronizados con el contenido de la base de datos, lo que a su vez significa una sobrecarga considerable del motor de la base de datos.

Irónicamente, por lo tanto, los intentos de acelerar las consultas SELECT pueden llevar a una base de datos más lenta en general. Este es un caso clásico de sobre indexación.

Este problema se puede resolver con un solo índice para todas las columnas y que sea distinto de la clave primaria utilizada para consultar la tabla.

También puede ordenar las columnas de la más utilizada a la menos utilizada. La indexación siempre es un equilibrio delicado y se trata de hacerlo bien.

Una sola tabla para todos los valores de dominio

Una tabla de dominios que abarca todo no es el mejor enfoque para el diseño de bases de datos.

Recuerda que las bases de datos relacionales se basan en la idea de que cada objeto en la base de datos es representativo de una sola cosa.

No debe haber ambigüedad sobre lo que se refiere a cualquier conjunto de datos.

Al navegar por a traves de la clave primaria, el nombre de la tabla, el nombre de la columna y las relaciones, uno debe descifrar rápidamente lo que significa un conjunto de datos.

Sin embargo, un concepto erróneo persistente sobre el diseño de la base de datos, es que mientras más tablas existan, más confusa y compleja será la base de datos.

Esta es a menudo la razón para condensar varias tablas en una tabla en el supuesto de que simplificará el diseño.

Suena como una buena idea, pero generalmente termina con una base de datos ineficiente y poco manejable.

El código SQL será largo, difícil de leer y poco natural. Será mezclar manzanas y naranjas.

A primera vista, las tablas de dominio parecen un contenedor abstracto de texto.

Esto es cierto desde el punto de vista de la implementación, pero no es la mejor manera de diseñar una base de datos.

Como parte del proceso de normalización, el aislamiento y la descomposición de los datos finaliza en que cada fila que representa una sola cosa. Y cada tabla de dominio es distinta de todas las demás tablas de dominio.

El resultado final de varias tablas de dominio es:

  • Se vuelve mucho más fácil utilizar los datos en las consultas.
  • Los datos pueden validarse de forma más natural con restricciones de clave foránea, algo que no es práctico para el diseño de una tabla de dominio única. Podrías hacerlo con la tabla de un solo dominio, pero las claves requeridas para cada tabla harían que el mantenimiento fuera un campo minado.
  • Siempre que necesites agregar más datos sobre un determinado objeto, la tarea es tan simple como agregar una o más columnas.
  • Las tablas de dominio pequeño cabrán en una sola pagina del disco duro, a diferencia de una tabla de dominio grande que probablemente se extenderá en varias secciones del disco. Tener las tablas en una sola página significa que la extracción de datos se puede lograr con una sola lectura de disco.
  • Tener varias tablas de dominio no le impide usar un editor para todas las filas. Las tablas de dominio probablemente tienen el mismo uso / estructura subyacente.

Convenciones de nombres deficientes o inconsistentes

Los diseñadores y desarrolladores de bases de datos a menudo ven su papel como uno totalmente técnico.

Los aspectos no técnicos, como la adhesión a las convenciones de nomenclatura, tienden a ser bajados a los escalones más bajos de la lista de prioridades o incluso se ignoran por completo. Esto puede ser un error catastrófico.

El nombre puede ser a discreción del diseñador, pero es, de hecho, el primer y más importante elemento de la documentación de la base de datos (exploraremos los errores de documentación en el siguiente punto).

Los diseñadores de bases de datos deben ver su trabajo como algo que vivirá mucho después de haberse mudado a otro empleador o rol diferente.

Las convenciones de nomenclatura tienen la finalidad de facilitar que las personas que no participaron en el proyecto comprendan rápidamente el contenido de las tablas y columnas.

Ningún administrador, programador o usuario futuro debe tener que leer un documento de 1000 páginas para comprender qué significa un determinado nombre de tabla o columna.

Los detalles exactos sobre cómo se debe nombrar sus tablas no están acordados por unanimidad por la industria.

Sin embargo, lo más importante es la consistencia. Una vez que sigas un estilo específico para nombrar los objetos, manténlos en toda la base de datos.

En la medida de lo posible, los nombres de las tablas deben ser una descripción completa o contratada de lo que representa la tabla, mientras que el nombre de cada columna debe aclarar rápidamente qué información representa.

Para bases de datos simples, esto no es difícil de hacer. Sin embargo, las cosas pueden complicarse una vez que se crean tablas que hacen referencia entre sí. Seguir estrictamente las convenciones de nomenclatura es la forma correcta trabajar.

Dicha convención incluye no tener un límite de caracteres en la longitud de los nombres de columnas o tablas para eliminar la necesidad de usar siglas que no se entiendan o recuerdan fácilmente.

Considera el nombre de columna CUST_DSCR. Cualquiera que lea eso tendrá que hacer conjeturas alocadas sobre lo que contiene esa columna. CUSTOMER_DESCRIPTION sería un nombre de columna mucho mejor y no obliga al lector a estirar su imaginación.

Evite la redundancia: en una tabla llamada “Estudiantes”, no necesita tener columnas etiquetadas como StudentName, StudentAddress o StudentGrade cuando Name, Address y Grade son suficientes.

Además, no utilices palabras reservadas. Etiquetar una columna como ‘Index’ puede ser confuso y ser una fuente de errores. En cambio, debes colocarla con un prefijo descriptivo como StudentIndex.

 

Documentación pobre

Si los desarrolladores y diseñadores de bases de datos tienen un problema al priorizar las convenciones de nombres, tienen un problema mucho mayor con la documentación.

Para un desarrollador, la documentación a veces se siente como un aspecto trivial no esencial del proceso de desarrollo.

Sin embargo, muchas bases de datos diseñadas de forma excelente han muerto en el altar de la documentación deficiente. La documentación deficiente inhibe en gran medida la solución de problemas, las mejoras estructurales, las actualizaciones y la continuidad.

Los diseñadores de bases de datos siempre deben imaginar que en algún momento ya no participarán en el soporte de la base de datos.

La documentación debería facilitar que otra persona se haga cargo del diseño, desarrollo o administración de la base de datos.

Una buena documentación debe contener definiciones de columnas, tablas, relaciones y restricciones que aclaren cómo se debe utilizar cada elemento.

Tendrás un mayor impacto si puedes incluir muestras que ilustren qué valores se esperan.

Algunos diseñadores utilizarán documentación deficiente para garantizar la seguridad en el trabajo, es decir, nadie más que ellos puede entender completamente la base de datos.

Esta es una estrategia corta de vista y condenada, ya que casi siempre lleva a la gestión a ver a través de las intenciones del diseñador.

La documentación deficiente también hace que a ti, como diseñador, te resulte más difícil volver años más tarde para volver a trabajar y mejorar el código.

 

Pruebas inadecuadas

Puede seguir meticulosamente todos los pasos necesarios para diseñar una base de datos de clase mundial.

Sin embargo, dará un salto ciego hacia la oscuridad si no sometes la base de datos a pruebas rigurosas.

Desafortunadamente, la fase de prueba es la que más sufre cuando un proyecto se está retrasando.

Sin embargo, es contraproducente porque una base de datos apresurada rápidamente se atascará por errores e inconsistencias que fácilmente se habrían identificado y resuelto durante la fase de pruebas.

Una base de datos llena de errores se convertirá en un problema para los usuarios y administradores. Caerás un pozo de reputación del que tendrás que luchar incluso cuando los errores se solucionen.

Cuando se realizan pruebas profundas y expansivas antes de que la base de datos se active, se reduce en gran medida el número y la escala de fallas después de la subida a producción.

Las pruebas no encontrarán todos los errores, pero ciertamente te ayudarán a deshacerte de la mayoría de ellos.

 

El desarrollo y el diseño de bases de datos son la base de cualquier proyecto de uso intensivo de datos, que incluye casi todas las aplicaciones empresariales.

Por lo tanto, el proceso de diseño siempre debe verse en este contexto.

Los errores de diseño enumerados en este artículo pueden parecer pequeños e insignificantes al principio.

Sin embargo, eventualmente, deterioran en gran medida el rendimiento de la base de datos y son costosos de arreglar.

Al asegurarse de hacer las cosas bien desde el primer momento, aumentas las posibilidades de crear una base de datos que sea adecuada para tu propósito.

Mokhtar Ebrahim
Estoy trabajando como administrador de sistemas Linux desde 2010. Soy responsable de mantener, proteger y solucionar problemas de servidores Linux para múltiples clientes de todo el mundo. Me encanta escribir guiones de shell y Python para automatizar mi trabajo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *