java - example - Hibernate/JPA DB Schema Generation Mejores prácticas

jpa java

Question

Solo quería escuchar la opinión de los expertos de Hibernate sobre las mejores prácticas de generación de esquemas DB para proyectos basados ​​en Hibernate / JPA. Especialmente:

1. ¿Qué estrategia usar cuando el proyecto acaba de comenzar? ¿Se recomienda dejar que Hibernate genere automáticamente el esquema en esta fase o es mejor crear las tablas de la base de datos manualmente desde las primeras fases del proyecto?

2. Fingiendo que durante todo el proyecto el esquema se estaba generando utilizando Hibernate, ¿es mejor desactivar la generación automática de esquemas y crear manualmente el esquema de la base de datos justo antes de que el sistema se lance a producción?

3. Y después de que el sistema se haya lanzado a producción, ¿cuál es la mejor práctica para mantener las clases de entidad y el esquema de DB (por ejemplo, agregar / renombrar / actualizar columnas, renombrar tablas, etc.)?

Answer 1

1. Siempre se recomienda generar el esquema de forma manual, preferiblemente mediante una herramienta que Liquibase revisiones de esquemas de bases de datos, como la gran Liquibase . Generar el esquema a partir de las entidades es genial en teoría, pero fue frágil en la práctica y causa muchos problemas en el largo plazo (créanme sobre esto).

2. En producciones, siempre es mejor tener generado manualmente y revisar el esquema.

3. Hace una actualización de una entidad y crea un script de actualización coincidente (revisión) para actualizar su esquema de base de datos para reflejar el cambio de entidad. Puede crear una solución personalizada (he escrito algunas) o usar algo más popular como liquibase (incluso admite reversiones de cambios de esquema). Si está utilizando una herramienta de compilación, como maven o ant, se recomienda conectar la herramienta de actualización de esquema db en el proceso de compilación para que las compilaciones nuevas permanezcan sincronizadas con el esquema.

Answer 2

Aunque es discutible, diría que la respuesta a las 3 preguntas es: deje que hibernate genere automáticamente las tablas en el esquema.

No he tenido ningún problema con eso hasta ahora. Es posible que tenga que limpiar algunos campos manualmente de vez en cuando, pero esto no es un dolor de cabeza en comparación con hacer un seguimiento de las secuencias de comandos DDL, es decir, gestionar sus revisiones y sincronizarlas con los cambios de entidad (y viceversa)

Para implementar en producción, un consejo obvio, primero asegúrese de que todo se genere correctamente en el entorno de prueba y luego impleméntelo en producción.

Answer 3

Como dijo Bozhidar, no permita que Hibernate cree y actualice el esquema de la base de datos. Deje que su aplicación cree y actualice el esquema de la base de datos. Para Java, la mejor herramienta para hacer esto es Flyway . Necesita crear uno o más archivos SQL con sentencias DDL que describen su esquema de base de datos. Estos archivos SQL son ejecutados por Flyway. Para obtener más información, consulte el sitio de Flyway .

Answer 4

Creo que mucho de lo que se está discutiendo o discutiendo aquí también debería estar relacionado con si está más cómodo con el enfoque primero de código o de base de datos.

Personalmente, estoy más interesado en este último y, haciendo referencia al Principio de Responsabilidad Individual (SRP), prefiero que el especialista de DB maneje el DB y un especialista en aplicaciones que maneje la aplicación, que tener la aplicación manejando el DB. Además, soy de la opinión de que tomar demasiados atajos funcionará bien al principio, pero creará problemas inmanejables a medida que las cosas crezcan / evolucionen.

Answer 5

Manualmente, porque:

1. Las diferentes aplicaciones pueden usar la misma base de datos y no todas usarán hibernate o incluso java. El esquema de la base de datos no debe ser dictado por ORM, debe diseñarse según los requisitos de datos y de negocio.
2. Los tipos de datos elegidos por Hibernate pueden no ser los más adecuados para la aplicación.
3. Como se mencionó en un comentario anterior, los cambios en las entidades requerirían una intervención manual si la pérdida de datos no es aceptable.
4. Las cosas como propiedades adicionales (término genérico, no propiedades de Java) en tablas de combinación funcionan maravillosamente en RDBMS, pero son algo complejas e ineficientes de usar en un ORM. Hacer una asignación de este tipo desde ORM -> RDBMS podría crear tablas que no son eficientes. En teoría, es posible construir exactamente la misma tabla de unión usando el código generado de hibernación, pero requeriría un cuidado especial al escribir las entidades.

Usaría la generación automática para aplicaciones independientes o bases de datos a las que se accede a través de la misma capa ORM y también si la aplicación necesita ser portada a diferentes bases de datos. Ahorraría mucho tiempo al no requerir que uno escriba y mantenga las secuencias de comandos DDL específicas del proveedor de BD.