Doctrine y Propel hacen uso de la herencia de tablas simples y concretas para mapear relaciones de objetos. El primero ve todos los campos posibles en el árbol de clases asignados a una sola tabla, mientras que el último asigna cada clase a una tabla específica, duplicando campos comunes en la jerarquía de herencia.
Si bien esto facilita el aparato ORM, me sugiere un mal diseño de la base de datos. ¿Son estos malos patrones de diseño para imponer en una base de datos?
Respuestas:
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 la normalización en general (hasta cierto punto) se ve como la mejor práctica, es bastante común desnormalizar áreas de bases de datos por razones de rendimiento, por lo que lo bueno y lo malo están muy abiertos a discusión sin mucha más información que la mayoría de las personas cuando comienzan.
Agregue los muchos enfoques que se pueden tomar 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 talla única, las bibliotecas de persistencia ORM casi siempre producirán una estructura de base de datos no óptima para cualquier situación dada y utilizarán algunas cosas que pueden considerarse una mala práctica para esa situación .
Ciertamente, podría escribir un ORM que se normalizara, pero vería implicaciones de rendimiento bastante considerables ya que para cada inserción en una tabla principal necesita escanear las diversas tablas de búsqueda para ver si existían valores, si obtuvieron sus claves y si no No realice las inserciones relevantes.
(Cuando hace esto a mano, puede acortar algo de esto, ya que sabe que les presentó un menú desplegable que contiene solo un valor válido, por lo que no necesita hacer estas búsquedas, solo puede usar la tecla feliz de que esté funcionando para ser válido, el ORM no pudo hacer esa suposición ya que no controla la interfaz de usuario).
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, sino la velocidad de desarrollo . Si la estructura específica de sus datos es importante para usted, entonces necesita codificar sus asignaciones de objetos / RDBMS a mano, o al menos hacer una evaluación detallada de todas las bibliotecas disponibles y seleccionar la que mejor se adapte a sus necesidades ( si existe)
Básicamente se trata de requisitos y el equilibrio entre datos bien estructurados, rendimiento de la 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 desnormalización o el 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 hacer que sea simple 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 la base de datos.
Posiblemente no promueve la normalización, pero de nuevo un ORM donde es fácil hacer tablas / objetos y relaciones casi podría verse 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 desee acceder también a la ubicación, debe unirse.
Entonces mi respuesta es: No, no lo creo . De hecho, posiblemente sea al revés, un buen ORM fomenta un buen diseño de la base de datos, al menos para aquellos que tienen poca experiencia.