Meilleures pratiques pour la génération de schémas de BD Hibernate/JPA

Question

Je voulais simplement connaître l'avis des experts d'Hibernate sur les meilleures pratiques de génération de schémas de base de données pour les projets basés sur Hibernate/JPA. En particulier :

1. Quelle stratégie utiliser lorsque le projet vient de démarrer ? Est-il recommandé de laisser Hibernate générer automatiquement le schéma dans cette phase ou est-il préférable de créer les tables de la base de données manuellement dès les premières phases du projet ?

2. En supposant que, tout au long du projet, le schéma était généré à l'aide d'Hibernate, est-il préférable de désactiver la génération automatique de schéma et de créer manuellement le schéma de la base de données juste avant la mise en production du système ?

3. Et après la mise en production du système, quelle est la meilleure pratique pour maintenir les classes d'entités et le schéma de la base de données (par exemple, ajouter/renommer/mettre à jour les colonnes, renommer les tables, etc.)

Merci d'avance.

Answer 1

1. Il est toujours recommandé de générer le schéma manuellement, de préférence à l'aide d'un outil prenant en charge les révisions de schéma de base de données, tel que l'excellent outil Liquibase . Générer le schéma à partir des entités, c'est bien en théorie, mais c'est fragile en pratique et cela cause beaucoup de problèmes à long terme (croyez-moi).

2. Dans les productions, il est toujours préférable de générer et de réviser manuellement le schéma.

3. Vous effectuez une mise à jour d'une entité et créez une mise à jour correspondante script(révision) pour mettre à jour votre schéma de base de données afin de refléter le changement d'entité. Vous pouvez créer une solution personnalisée (j'en ai écrit quelques unes) ou utiliser quelque chose de plus populaire comme liquibase (il supporte même les rollbacks des changements de schéma). Si vous utilisez un outil de construction tel que maven ou ant, il est recommandé d'intégrer l'utilitaire de mise à jour du schéma de la base de données dans le processus de construction afin que les nouvelles constructions restent synchronisées avec le schéma.

Answer 2

Bien que cela soit contestable, je dirais que la réponse à ces trois questions est : laissez Hibernate générer automatiquement les tables dans le schéma.

Je n'ai pas eu de problèmes avec ça jusqu'à présent. Vous devrez peut-être nettoyer certains champs manuellement de temps en temps, mais ce n'est pas un casse-tête comparé au fait de garder séparément la trace des scripts DDL, c'est-à-dire de gérer leurs révisions et de les synchroniser avec les modifications des entités (et vice-versa).

Pour le déploiement en production - un conseil évident - assurez-vous d'abord que tout est bien généré dans l'environnement de test et déployez ensuite en production.

Answer 3

Manuellement, car : 1. La même base de données peut être utilisée par différentes applications et toutes n'utiliseront pas hibernate ou même java. Le schéma de la base de données ne doit pas être dicté par l'ORM, il doit être conçu autour des données et des besoins de l'entreprise. 2. Les types de données choisis par Hibernate ne sont peut-être pas les mieux adaptés à l'application. 3. Comme mentionné dans un commentaire précédent, les modifications des entités nécessiteraient une intervention manuelle si la perte de données n'est pas acceptable. 4. Des éléments tels que les propriétés supplémentaires (terme générique et non propriétés java) sur les tables de jointure fonctionnent à merveille dans les SGBDR mais sont quelque peu complexes et inefficaces à utiliser dans un ORM. Un tel mappage de l'ORM au SGBDR peut créer des tables qui ne sont pas efficaces. En théorie, il est possible de construire exactement la même table de jointure en utilisant le code généré par Hibernate, mais cela nécessiterait une attention particulière lors de l'écriture des entités.

J'utiliserais la génération automatique pour les applications autonomes ou les bases de données auxquelles on accède via la même couche ORM et également si l'application doit être portée sur différentes bases de données. Cela permettrait de gagner beaucoup de temps en évitant d'avoir à écrire et à maintenir des scripts DDL spécifiques aux fournisseurs de bases de données.

Answer 4

Comme Bozhidar l'a dit, ne laissez pas Hibernate créer et mettre à jour le schéma de la base de données. Laissez votre application créer et mettre à jour le schéma de la base de données. Pour Java, le meilleur outil pour ce faire est le suivant Voie de migration