Objet Hibernate vs Modèle physique de base de données

Question

Y a-t-il un problème réel - comme les performances - lorsque le modèle d'objet Hibernate et le modèle physique de base de données ne correspondent plus? Toute préoccupation? Devraient-ils être synchronisés?

Notre système actuel a été conçu à l'origine pour un faible nombre d'utilisateurs, donc peu d'efforts ont été faits pour garder le physique et les objets synchronisés. Les développeurs ont accompli leur tâche et les architectes n'ont pas surveillé. Maintenant que nous sommes en train de réécrire/importer le système hérité dans le nouveau système, nous nous sommes inquiétés du fait que le système hérité gère beaucoup de volume utilisateur et pourrait mettre le nouveau système à genoux.

Mise à jour 20090331
des commentaires de Pete ci-dessous - la préoccupation était sur la table/relations de données dans la couche de données contre la couche d'objet. S'il n'y a pas de dépendances entre les deux, alors il n'y a pas de hits de performance si ces relations ne correspondent pas? Est-ce exact? Le souci de mon point de vue est que l'équipe de développement passe beaucoup de temps à "accorder" les requêtes/objets hibernate mais rien dans la couche de base de données pour améliorer les performances de l'application. J'aurais supposé qu'ils allaient régler les deux couches.

Est-ce que ces problèmes pourraient provenir d'une mauvaise conception initiale de la base de données pour commencer et essayer de couvrir/combler la différence en utilisant Hibernate?

(Je suis nouveau à ce projet afin de jouer catchup)

Answer 1

Mise à jour: en réponse au commentaire: Il est crucial que la base de données soit optimisée en plus de l'utilisation d'Hibernate. Quand on y réfléchit, après tout le travail d'hibernation, à la fin, il s'agit juste d'interroger la base de données. Si la base de données ne fonctionne pas correctement (index incorrects ou manquants, espaces de table mal configurés, etc.), peu importe le réglage de Hibernate. D'un autre côté, si votre base de données est bien configurée mais que Hibernate ne l'est pas (la mise en cache n'est peut-être pas correctement configurée, etc., et vous revenez plus souvent dans la base de données), les performances vont en souffrir. bien. Il est toujours important de régler le système de bout en bout, mais commencez à la base (base de données) et travaillez.

Fin Mise à jour

Je suis curieux de ce que vous entendez par « ne correspond pas à » - que tu veux dire des colonnes ont été ajoutées aux tables qui ne sont pas représentés dans les objets de données de mise en veille prolongée? Des tables ont été ajoutées? Je ne pense pas que cela affecterait les performances (intégrité des données plus probable si vous n'insérez/ne mettez pas à jour toutes les colonnes)

En général, l'objectif du modèle objet NE doit PAS correspondre au schéma de base de données mot pour mot. Vous voulez faire abstraction de la complexité/jointures/normalisation des données sous-jacentes, c'est tout l'intérêt d'utiliser quelque chose comme Hibernate.

Ainsi, par exemple permet de dire que vous avez (en gardant les choses très simples) « ordres » et les « articles de commande »,

votre code d'application doit être capable de faire quelque chose comme

order.getItems()

sans avoir à savoir qu'en dessous il y a une relation de un à plusieurs. Les détails de votre code d'hibernation contrôlent comment le chargement est fait (paresseux, mise en cache, etc.).

Si cela ne répond pas à votre question, veuillez fournir plus de détails.

Answer 2

Vous pouvez bien sûr code votre couche d'abstraction dans asm - « peut-être » (mot terrible pour un développeur) plus rapide.

Ceci est une optimisation prématurée - peut-être casser une mise en page de projet propre.

Comme dans le manuel d'hibernation, l'optimisation peut être différente - le codage simple de certaines parties «pourrait» en faire partie.

Answer 3

Il est certainement possible que les modifications que vous décrivez puissent entraîner des problèmes de performances. J'aurais pensé que cela aurait dû faire partie des spécifications de conception.
Donc, quand vous le codez, vous tenez compte des critères de performance. La seule façon de vraiment savoir est de charger les données dans un environnement de test et d'exécuter quelques tests.

Ceci devrait certainement être fait avant d'aller vivre, car il pourrait produire des résultats assez intéressants.