¿ORM promueve la des-normalización de la base de datos?

Es imposible decir si un diseño de base de datos en particular es malo sin saber qué está haciendo la aplicación, la forma de los datos, las expectativas de rendimiento, etc. Si bien en general se considera que la normalización (hasta cierto punto) es la mejor práctica, es bastante común desnormalizar áreas de las bases de datos por razones de rendimiento, por lo que tanto las buenas como las malas están mucho más abiertas para la discusión sin mucha más información de la que la mayoría de las personas tienen cuando comienzan.

Agregue los muchos enfoques que pueden adoptarse para objetar las asignaciones relacionales y las cosas se vuelven aún más complejas, ya que la "mejor" estructura de la base de datos dependerá del modelo de objeto específico, el nivel de herencia, etc.

Al adoptar un enfoque de tamaño único, las bibliotecas de persistencia ORM casi siempre producirán una estructura de base de datos no óptima para cualquier situación dada y usarán algunas cosas que pueden considerarse como una mala práctica para una situación dada .

Ciertamente, se podría escribir un ORM que se normalizara, pero vería implicaciones de rendimiento bastante elevadas, ya que para cada inserción en una tabla principal era necesario escanear las diversas tablas de búsqueda para ver si existían valores, si obtuvieron sus claves si no realizaron las inserciones correspondientes.

(Cuando haces esto a mano, puedes hacer un atajo de esto ya que sabes que los presentaste con un menú desplegable que contiene solo un valor válido, por lo que no necesitas hacer estas búsquedas, solo puedes usar la tecla feliz que va a ser válido, el ORM no pudo hacer esa suposición ya que no controla la UI).

Pero lo que debe recordar es que no tienen como objetivo optimizar el rendimiento de la base de datos o la integridad de los datos, se están optimizando para la velocidad de desarrollo . Si la estructura específica de sus datos es importante para usted, entonces debe codificar sus asignaciones de objetos / RDBMS a mano, o al menos realizar una evaluación detallada de todas las bibliotecas disponibles y seleccionar la que mejor se adapte a sus necesidades ( si existe uno.

Esencialmente se reduce a los requisitos y al intercambio entre datos bien estructurados, rendimiento de base de datos y velocidad de desarrollo. Al igual que con muchas compensaciones, no puedes elegir las tres.

No estoy de acuerdo con que ORM promueva la des-normalización o un mal diseño de la base de datos. De hecho, las bases de datos peor diseñadas que he visto se han hecho sin ORM. Al simplificar el hecho de tener relaciones adecuadas basadas en la identificación de fila en lugar de establecer una relación basada en el valor de un campo aleatorio, promueve un buen diseño de base de datos.

Posiblemente no promueva la normalización, pero nuevamente, un ORM donde es fácil hacer tablas / objetos y relaciones podría verse casi para promover eso también. No es mucho más trabajo en un ORM hacer una tabla de "ubicación" con direcciones y vincular a los empleados a la ubicación en lugar de agregar la dirección a la tabla de empleados. Pero sin el ORM, separar la ubicación significa que cada vez que quiera acceder también a la ubicación, debe hacer una unión.

Así que mi respuesta es: No, no lo creo . Es posible que, de hecho, sea de otra manera, un buen ORM aliente el buen diseño de la base de datos, al menos sobre aquellos que tienen poca experiencia.

Como regla general, nunca modele sus datos para satisfacer las necesidades del desarrollador (puede usar Views o Sp para eso, pero no el modelo de datos).

El modelo de datos debe basarse en las reglas comerciales de la aplicación y las necesidades de rendimiento.