¿Quién diseña bases de datos en desarrollo web? [cerrado]

En el contexto del desarrollo web, ¿quién diseña las bases de datos? A pesar de una gran cantidad de información que asocia el desarrollo web de back-end con el procesamiento del lado del servidor, el modelado de datos y similares, el aspecto del diseño de la base de datos de la ecuación parece estar misteriosamente ausente.

No estoy hablando de quién configura la base de datos física, me refiero a quién diseña el modelo lógico de la base de datos, realiza entrevistas de historias de usuarios para obtener información sobre qué campos son necesarios, cuáles son esas especificaciones de campo, etc. .

Me di cuenta de que el diseño ( ADECUADO ) de una base de datos no es una tarea pequeña (estoy leyendo este localizador 672) y podría ser fácilmente una profesión completa. Sin embargo, la búsqueda en Internet ha dado resultados sorprendentemente pequeños para quién se espera que maneje esta tarea en el contexto del desarrollo web.

Su pregunta no solo es pertinente para las aplicaciones web, sino también para todo tipo de aplicaciones que utilizan un backend de base de datos.

En mi experiencia

• El diseño de la base de datos es el trabajo combinado de desarrolladores y DBA.
• Los desarrolladores realizan diseños de bases de datos en bruto, o a menudo muy buenos. Todo depende de la experiencia de los programadores.
• A menudo, los desarrolladores crean tablas en su base de datos de desarrollo y a partir de ella se aplica un modelo conceptual.
• A menudo, los diagramas conceptuales de ER se discuten con otros miembros del equipo, a menudo clientes. En esta etapa, se detectan errores conceptuales obvios y, con suerte, se resuelven y corrigen.
• El trabajo del DBA es revisar dicho diseño y ajustarlo para detectar violaciones de las formas normales.
• Además, el DBA impone convenciones de nomenclatura de tablas y columnas.
• Además, el DBA visualiza posibles cuellos de botella en el rendimiento e intenta comprender cómo se consultarán los datos para crear índices apropiados más adelante.
• El ciclo de revisiones / verificación / reparación entre el desarrollador / diseñador de la aplicación y los DBA pasa por varias iteraciones hasta que el modelo es lo suficientemente maduro como para generar un modelo físico.
• Por lo general, se utiliza una herramienta de diseño de bases de datos en todas las bases de datos, excepto en las muy pequeñas, para ayudar en este proceso.

Línea de fondo:

• Los desarrolladores conocen el negocio y el dominio del problema mejor que los DBA, por lo que hacen la mayor parte del diseño inicial y, dependiendo de la experiencia del desarrollador, dicho diseño puede estar muy cerca del diseño final.
• La función del DBA es principalmente garantizar NF, convenciones de nomenclatura, consideraciones de rendimiento, corregir errores obvios y finalmente generar un modelo físico, luego un script específico de la base de datos y ejecutarlos para crear la base de datos.
• Diría que es un 80% de trabajo de análisis de requisitos y desarrollador y un 20% de trabajo de DBA.

ACTUALIZAR:

Hay 3 tipos de DBA:

• DBA de desarrollo que conocen el modelado de datos, son expertos en SQL y pueden escribir procedimientos almacenados, generalmente son desarrolladores anteriores;
• DBA de producción que se especializan en instalación, ajuste de rendimiento, copias de seguridad y restauración, etc.
• y los DBA de todo tipo que han trabajado haciendo todas esas cosas y, como tales, pueden hacer la mayoría (son muy pocos).

La mayoría de los DBA son DBA de producción, lo cual es bueno porque son los tipos que recuperan bases de datos perdidas de matrices de discos fallidas en las primeras horas de la noche. Pero no participan activamente en el proceso de diseño.

Depende de para qué se utiliza la base de datos.

En muchas aplicaciones (aplicaciones web o no), la base de datos está íntimamente ligada a esa aplicación porque sirve como almacén permanente para ella. Entonces, la base de datos es conceptualmente parte de la aplicación, por lo que está diseñada en conjunto (y presume que ningún otro programa accedería o actualizaría significativamente esa base de datos). Por cierto, la persistencia podría lograrse por otros medios que no sean una base de datos, por ejemplo, archivos de texto sin formato, archivos binarios (especialmente archivos indexados a la GDBM ), repositorios git (u otro VCS), directorios o árboles de archivos, particiones de disco sin procesar, hardware dedicado (por ejemplo flash), sistemas de archivos remotos, puntos de controltécnicas Para las bases de datos diseñadas para y con una aplicación, debe preocuparse por los patrones comunes de recuperación y actualización y diseñar el esquema de la base de datos (¡y la indexación!) Teniendo en cuenta estos.

En algunas situaciones, la base de datos es en sí misma un activo importante e independiente, y está diseñada a priori para ser utilizada por varias aplicaciones diferentes (e incluso futuras). Entonces debe diseñarse de forma independiente (y mucho más cuidadosamente).

En particular, algunas aplicaciones web son solo interfaces web para bases de datos existentes.

En muchos casos (piense en algunos wiki como ejemplo), los datos son más importantes y más valiosos que las aplicaciones que los usan. Puede que le interese cómo hacer que sea a prueba de futuro y poder evolucionarlo fácilmente (por ejemplo, utilizando o definiendo formatos textuales y versátiles, preferiblemente estandarizados y documentados, para hacer una copia de seguridad y restaurarlo).

Me he dado cuenta de que el diseño (CORRECTO) de una base de datos no es tarea fácil ...

Lea también sobre NoSQL , bases de datos orientadas a documentos , bases de datos de valores clave , la gestión del conocimiento , representación del conocimiento , ontologías , sistemas expertos , las reglas de negocio se acercan , ERP , CMS . Quizás considere usar REDIS , MongoDB , etc.