¿Es el trabajo de los programadores diseñar la base de datos?

He sido programador durante los últimos seis años. A lo largo de mi carrera, he trabajado en muchas aplicaciones web.

La mayoría de las veces, cuando se necesitaba una base de datos, nos la dieron a nosotros (los programadores) o teníamos alguna base de datos heredada para trabajar. Si no es así, tuvimos que crear y diseñar la base de datos por nuestra cuenta, lo que no fue tan difícil.

¿Pero se supone que, como programadores, creamos la base de datos completa desde cero cuando tenemos que construir una nueva aplicación donde los datos son tan importantes y tenemos requisitos desordenados con un modelo de datos complejo?

¿No es lo mejor para la aplicación y la empresa que un experto lo haga?

No estoy tratando de huir del diseño de la base de datos, pero es algo muy importante para hacerlo bien.

En primer lugar, es su trabajo si el gerente del proyecto se lo dice. Las empresas más pequeñas a menudo no tienen expertos en bases de datos a tiempo completo. De todos modos, no hay (y no debería haber) una distinción clara entre desarrolladores y expertos en bases de datos: cualquier buen desarrollador tendrá un conocimiento considerable sobre las bases de datos, y cualquier buen DBA sabrá cómo codificar, al menos en el lenguaje de la base de datos para procedimientos almacenados .

Si bien el diseño de la base de datos es una parte bastante central de una aplicación, no es más importante "acertar" que otras partes centrales de las que dependerá mucho otro código.

Y al igual que el código, la idea de que consigas un súper experto para sentarse y pensar mucho durante una semana y luego escribir el diseño perfecto que nunca necesitará cambiar es una ilusión. El diseño de la base de datos puede y cambiará a medida que se desarrolle la aplicación.

Por lo tanto, es realmente beneficioso tener el DB diseñado por un programador (que entiende bien los DB), porque entonces tienes a alguien que conoce ambos lados. Eso es ciertamente mejor que hacerlo alguien que solo entienda los DB y no tenga nada que ver con el resto del trabajo de desarrollo.

Es común que los programadores hagan la base de datos. Muy común. Desafortunadamente, muchos programadores no tienen experiencia con el DB. No entienden cómo informar contra big data, los conceptos de data marts, esquemas en estrella, etc. Algunos ni siquiera entienden los conceptos básicos de la normalización.

Si un hombre tiene las habilidades para hacer todo a nivel experto, es un muy buen producto. Un ejército de un solo hombre puede hacer lo que un equipo de 10 hombres puede hacer en una fracción del tiempo con 1000 veces la calidad. No es una exageración.

Lo mejor para el programador es hacerlo (menos personas), suponiendo que el programador sepa lo que está haciendo. Por supuesto, hay miles de fallas para señalar también.

Es una pregunta interesante: hay un fuerte argumento de que la mayoría de los desarrolladores decentes deberían entender cómo estructurar adecuadamente una base de datos relacional, es decir, deberían ser capaces de producir un esquema normalizado y, basándose en la experiencia y patrones comunes, hacer razonables decisiones sobre cómo deben estructurarse los datos almacenados (para mí es en su mayoría evidente por sí mismo, pero sé que no todos lo ven de esa manera).

Además, si nos fijamos en Entity Framework Code-first que sugiere que el mismo pensamiento que se aplica a la construcción de un modelo de datos de bajo nivel producirá un esquema razonable, o al menos una pista.

Entonces, no, no creo particularmente que necesite un experto en bases de datos para diseñar un esquema de base de datos, al menos no para bases de datos pequeñas y medianas (que son las cosas en las que he trabajado).

El problema es que el diseño de un esquema bueno (o al menos adecuado) no es toda la historia, especialmente si la base de datos tiene que escalar. Me parece que el "valor agregado" aportado por un DBA está en obtener las cosas que no sean el esquema básico correcto: índices, configuración de almacenamiento, mantenimiento de la base de datos (mantener el tamaño de los archivos bajo control, reconstruir índices, etc.), ser más inteligente con usuarios y roles, y así sucesivamente.

Un buen programador debería aportar una cartera diversa de habilidades: debería ser más que un codificador [insertar idioma de elección] e incluiría la comprensión de las bases de datos en esa cartera.

Creo que la capacidad de diseñar una base de datos relacional razonable es esencialmente una necesidad para los programadores no junior.

Dicho esto, particularmente para aplicaciones grandes, es vital que la base de datos sea "correcta" la primera vez (esquema, indexación, etc.). Si la empresa tiene acceso a un DBA calificado, esa tarea debe recaer en su plato; en general estarán más calificados. Potencialmente, la revisión / discusión debe hacerse con el desarrollador principal que accederá y trabajará con la base de datos en el lado del cliente para que no haya sorpresas. Si no hay DBA, el programador diseña la base de datos.

Veo dos preguntas aquí:

• ¿Deben los desarrolladores de bases de datos modelar la lógica empresarial?
• ¿Debo saber cómo conservar los datos en la base de datos?

Lógica de negocios

• La lógica empresarial no vive en una base de datos. Es un modelo conceptual que debe ser independiente de otras capas dentro de su sistema.

• Siempre puede reemplazar una base de datos con otra, o incluso puede decidir usar soluciones NoSQL para abordar posibles problemas de rendimiento.

• Los desarrolladores de bases de datos pueden participar durante el proceso de modelado, pero normalmente esto lo hacen personas con un conocimiento completo de un dominio problemático. En nuestra organización, esto lo hacen los desarrolladores del lado del servidor.

• Muchos piensan que la base de datos es la base de su aplicación. Haga una base pobre, y el sistema caerá. No estoy de acuerdo con esto. Veo la base de datos como un medio de almacenamiento que siempre se puede reemplazar.

Datos persistentes

• Debe saber cómo conservar los datos en diferentes medios de almacenamiento, incluidas las soluciones SQL y NoSQL.

• El nivel de experiencia requerida variará con el tamaño del sistema en el que está trabajando.

• Las pequeñas empresas esperarían que usted tenga ese conocimiento, cuando las grandes empresas normalmente contratan expertos para abordar los requisitos relacionados con el rendimiento, la escalabilidad y la seguridad.

Resumir:

• El modelo de dominio es la base de su sistema, no la base de datos.

• Si trabaja para una empresa pequeña en un proyecto relativamente pequeño, entonces probablemente debería diseñar la base de datos usted mismo.

• Si trabaja para una gran empresa en un sistema empresarial, entonces probablemente tenga más sentido pasar el trabajo a los expertos de dominio.