ORM favorise-t-il la dénormalisation de la base de données?

Doctrine et Propel utilisent tous deux l'héritage de table unique et concret pour mapper les relations d'objet. Le premier voit tous les champs possibles de l'arborescence des classes mappés sur une seule table - tandis que le second mappe chaque classe sur une table spécifique, dupliquant les champs communs dans la hiérarchie d'héritage.

Bien que cela facilite l'appareil ORM, cela me suggère une mauvaise conception de la base de données. Ces mauvais modèles de conception doivent-ils être appliqués à une base de données?

Il est impossible de dire si une conception de base de données particulière est mauvaise sans savoir ce que fait l'application, la forme des données, les attentes en matière de performances, etc. Bien que la normalisation (dans une certaine mesure) soit généralement considérée comme la meilleure pratique, il est assez courant de dénormaliser les zones de bases de données pour des raisons de performances, si bonnes et mauvaises sont très ouvertes à la discussion sans beaucoup plus de données que la plupart des gens quand ils commencent.

Ajoutez les nombreuses approches qui peuvent être prises pour s'opposer aux mappages relationnels et les choses deviennent encore plus complexes car la "meilleure" structure de base de données dépendra du modèle d'objet spécifique, du niveau d'héritage, etc.

En adoptant une approche unique, les bibliothèques de persistance ORM produiront presque toujours une structure de base de données non optimale pour une situation donnée et utiliseront certaines choses qui peuvent être considérées comme une mauvaise pratique pour cette situation donnée .

Vous pourriez certainement écrire un ORM normalisé, mais vous verriez des implications de performances assez lourdes, car pour chaque insertion dans une table principale, il fallait analyser les différentes tables de recherche pour voir si des valeurs existaient, si elles ont obtenu leurs clés et si elles ne l'ont pas été. 'effectuer les insertions pertinentes.

(Lorsque vous faites cela à la main, vous pouvez raccourcir une partie de cela car vous savez que vous leur avez présenté un menu déroulant contenant uniquement une valeur valide afin que vous n'ayez pas besoin de faire ces recherches, vous pouvez simplement utiliser la clé heureuse que cela se passe pour être valide, l'ORM n'a pas pu faire cette hypothèse car il ne contrôle pas l'interface utilisateur.)

Mais vous devez vous rappeler qu'ils ne visent pas à optimiser les performances de la base de données ou l'intégrité des données, ils optimisent la vitesse de développement . Si la structure spécifique de vos données est importante pour vous, vous devez soit coder vos mappages objet / SGBDR à la main, soit tout au moins faire une évaluation détaillée de toutes les bibliothèques disponibles et sélectionner celle qui répond le mieux à vos besoins ( s'il en existe un).

Il s'agit essentiellement d'exigences et de compromis entre des données bien structurées, les performances des bases de données et la vitesse de développement. Comme pour de nombreux compromis, vous ne pouvez pas choisir les trois.

En règle générale, ne modélisez jamais vos données pour répondre aux besoins du développeur (vous pouvez utiliser Views ou Sp pour cela, mais pas le modèle de données).

Le modèle de données doit être basé sur les règles métier de l'application et les besoins de performances.

Je ne suis pas d'accord que ORM favorise la dénormalisation ou une mauvaise conception de base de données. En fait, les bases de données les plus mal conçues que j'ai vues se sont déroulées sans ORM. En simplifiant les relations appropriées basées sur l'ID de ligne au lieu de créer une relation basée sur la valeur d'un champ aléatoire, cela favorise plutôt une bonne conception de la base de données.

Peut-être que cela ne favorise pas la normalisation, mais là encore, un ORM où il est facile de créer des tableaux / objets et des relations pourrait presque aussi être vu comme favorisant cela. Ce n'est pas beaucoup plus de travail dans un ORM pour créer une table "emplacement" avec des adresses et lier les employés à l'emplacement au lieu d'ajouter l'adresse à la table des employés. Mais sans l'ORM, séparer l'emplacement signifie que chaque fois que vous souhaitez également accéder à l'emplacement, vous devez vous joindre.

Ma réponse est donc: non, je ne pense pas . C'est peut-être en fait une autre solution, un bon ORM encourage une bonne conception de base de données, du moins pour ceux qui ont peu d'expérience.