Al escribir una publicación de blog sobre el modelado de bases de datos, debe estar preparado para que su modelo abstracto no satisfaga las necesidades de la mayoría de los lectores. La razón es simple. Los modelos de bases de datos de la vida real generalmente se crean en estrecha relación con los requisitos comerciales y de desarrollo específicos, mientras que los modelos de blog no.
Durante las últimas semanas, he estado escribiendo publicaciones de blog sobre la creación de modelos de bases de datos. Los temas variaron desde un enfoque general para el modelado de bases de datos a través de un simple foro en línea hasta un modelo para una encuesta en línea más compleja.
Para cada modelo de base de datos que creo, trato de comprender claramente el dominio comercial y elaborar en mi mente el panorama general del modelo.
El desafío del desarrollo de bases de datos abstractas
Normalmente, como solución arquitecto , tomo requisitos comerciales específicos y los convierto en detalles técnicos de lo que se debe crear desde el punto de vista técnico:traducir del lenguaje comercial al lenguaje técnico:diseñar los algoritmos a un alto nivel y modelar los requisitos de datos para los algoritmos.
Desafortunadamente, no puedo bloguear sobre los modelos de bases de datos del mundo real que creo en el trabajo. Por un lado, son muy específicos del dominio comercial y, por otro, estoy restringido por acuerdos de confidencialidad. Para el blog, creo un puramente abstracto concepto sin requisitos comerciales específicos, excepto aquellos que imagino que existen dentro del dominio comercial. Ahora, eso está bien; Tengo una imaginación bastante buena y señalo con frecuencia que sus requisitos pueden ser diferentes cuando describo las elecciones que estoy haciendo. Pero este proceso de creación de blogs me hizo pensar en lo diferente que es este proceso de crear los modelos en un proyecto real.
El proceso de desarrollo de la vida real
En una situación real, trabajaría en estrecha colaboración con el equipo de desarrollo después de crear la solución de alto nivel y el diseño técnico en un entorno interactivo. para que el modelo se ajuste a las necesidades de desarrollo.
Los desarrolladores pueden quejarse de que el modelo de datos está demasiado normalizado para admitir un alto rendimiento o pueden solicitar una normalización adicional en ciertas áreas. Si faltara alguna clave alternativa, los desarrolladores se quejarían con bastante rapidez y también lo notaríamos durante las pruebas de rendimiento de la base de datos.
Consideraríamos cuáles deberían ser las longitudes exactas de los campos en función de la longitud máxima de los datos que se almacenarán y del diseño de las pantallas para la entrada y visualización de los datos. Por supuesto, las longitudes de campo exactas en un modelo de base de datos conceptual no son importantes.
Trabajaríamos con ejemplos de qué datos se almacenarán en las tablas y cómo la aplicación los usará, y crearíamos scripts para completar previamente las tablas para las pruebas unitarias de la aplicación. De esta forma, atraparíamos los casos de esquina para asegurarnos de que el modelo soporta los límites de la aplicación.
Entonces, básicamente, modificaríamos el modelo hasta que realmente admita los requisitos comerciales y no funcionales del sistema mediante un proceso iterativo hasta que hayamos desarrollado un modelo en algo que todos podamos aceptar a pesar de los compromisos incorporados.
Como dije, sería un proceso muy iterativo que podría continuar durante muchos meses mientras se desarrollan el código de la aplicación, las interfaces de usuario y las interfaces de la aplicación.
Limitaciones de los comentarios bien intencionados
En la situación actual de los blogs, si bien mi número de lectores, ciertamente limitado, me brinda retroalimentación sobre los problemas y desafíos que observan con los modelos, es necesariamente superficial. Dudo que alguno de los lectores esté usando directamente los modelos para crear una aplicación y descubrir qué funciona realmente y dónde hay problemas.
Así que los comentarios como "el modelo no está bien pensado" tienen casi toda la razón. Por otro lado, "faltan FK" es bastante preciso, pero espero haber explicado en el texto del artículo por qué incluyo una clave externa o no.
Conclusión
Ahora, no lea esta publicación como una queja o un comentario sobre los comentarios que los lectores están haciendo, sino que estoy reflexionando sobre la dificultad de hacer un modelo de base de datos cuando no se encuentra en un entorno que permite un intercambio interactivo con un iterativo. proceso de desarrollo.
Probablemente haya otras situaciones en las que los modeladores de bases de datos estén aislados del proceso de desarrollo, pero ahora me he dado cuenta de lo peligroso que sería y de lo propensos que serían a los problemas.
¿Te imaginas un modelo de base de datos que nunca se cambia? Nunca un solo ajuste de una columna, nunca la adición de una clave externa, nunca la necesidad de una nueva tabla. Honestamente, la única situación que puedo imaginar así es cuando la aplicación que usa la base de datos ya no está evolucionando y ha llegado a un callejón sin salida:el final de su vida útil.
