Discussion :

[Syntcpip]

je vous remercie pour votre aide

[fsmrel]

Bonjour Syntcpip,

Si j’ai pu vous aider...
N’oubliez pas que pour les médailles en chocolat qui font toujours plaisir, si vous avez deux minutes, c’est ici.

[Syntcpip]

D'accord merci encore!

[Rhona Maxwel]

Hibernate est l'outil standard d'ORM (Object Relational Mapping), pour avoir une correspondance entre un modèle objet et un modèle relationnel (SQL).
Voir l'article https://www.urbanisation-si.com/a-ma...oute-categorie

[CinePhil]

ORM : Outil Réellement Merdique !

Le plus important est la bonne conception du modèle de données puis son implémentation en base de données. Ensuite, on utilise des vues auxquelles s'adresse le programme et qui, elles, peuvent correspondre à une vision objet de l'application.

Ce n'est pas l'application qui définit le modèle de données ! Elle ne fait que l'utiliser.

[Rhona Maxwel]

Bonjour,

Effectivement la réussite d'un développement d'une application repose sur sa conception.
La modélisation UML de la conception apporte beaucoup d'avantages, comme l'étude de plusieurs solutions et la vérification à moindre coût, l'utilisation de patterns éprouvés, la simulation, la documentation, la génération de code et la génération de la base de données.
Si la conception objet est bien optimisée, le générateur sort un schéma de base correcte pouvant être éventuellement retouché par un DBA.

Les requêtes SQL standards sont elles aussi générées à partir de langage comme JPQL.
Les requêtes plus complexes sont en SQL et même en SQL natif au RDBMS.

Il faut reconnaître que tout ce qui provient d'un générateur est plus verbeux et plus lent que ce qui est réalisé par un expert.

La plupart du temps dans des très gros projets, une partie de la base de données, le paramétrage par exemple à cycle de vie long, est entièrement chargé en RAM ce qui donne des temps de réponses très correctes.

[CinePhil]

Si la conception objet est bien optimisée, le générateur sort un schéma de base correcte pouvant être éventuellement retouché par un DBA.

Non parce qu'un modèle objet fidèle au métier n'a rien à voir avec un modèle relationnel.

Exemple simple...

Une classe Salarie va être modélisée avec le nom patronymique, le nom d'usage, les prénoms, l'adresse postale, le téléphone fixe, le téléphone mobile, l'adrel, la date d'entrée dans l'entreprise...

Mais dans la base de données, l'adresse sera éclatée au moins en référençant une table des villes et le reste des attributs de l'adresse dans la table des adresses, laquelle sera référencée par la table des salariés si on ne conserve qu'une seule adresse postale ou par une table associative référençant l'adresse et le salarié si on considère (à juste titre) que plusieurs salariés peuvent habiter à la même adresse (dans le même immeuble à entrée unique, par exemple).

D'une manière générale, les données sont bien plus éclatées dans une base de données relationnelle que dans un modèle objet métier.

Je pense d'ailleurs que c'est parce que des bases de données ont été faites à partir de l'application qu'elles ont en fait un modèle pourri qui finit par nuire aux performances (exemples : les CMS, Jira, GLPI, Moodle...).

Autre défaut des ORM : les requêtes complexes sont encore plus complexes à écrire avec leur pseudo langage SQL et l'exécution de ces requêtes un tant soit peu complexes entraîne le lancement de multiples requêtes SQL sur la BDD et l'importation dans l'application de données inutiles. J'avais constaté ça il y a quelques années avec Hibernate sur un projet utilisant JBoss Tools. Il vaut bien mieux écrire de vraies requêtes SQL et les balancer directement à la BDD ou bien utiliser des vues et ne laisser l'application accéder à la BDD que via des vues et/ou des procédures SQL.