Deseamos regalarte la mejor información que descubrimos online. Queremos que te sirva de ayuda y si puedes aportar alguna mejora hazlo libremente.
Solución:
Prefiero modelar la base de datos primero. La base de datos es la parte más valiosa del negocio, la lógica de la aplicación es solo una interfaz para manipular los datos comerciales.
Dado que las bases de datos tienden a sobrevivir a las tecnologías de aplicación, es mejor diseñarlas por adelantado, ya que el diseño generalmente se basa en las relaciones de datos y el modelo de consulta de datos.
La mayoría de los ORM fueron diseñados para modelar objetos de dominio a esquemas existentes y es la tarea de la herramienta ORM hacer frente a cualquier posible problema de mapeo de esquemas de base de datos.
Para la creación rápida de prototipos, podría considerar hacer que mi esquema se genere a partir de los objetos de dominio, pero al diseñar una arquitectura de sistema empresarial grande, este enfoque no es óptimo.
Hibernate solo ofrece un número limitado de funciones DDL y no me gusta perder funciones adicionales específicas de DB como dominios PosgreSQL, en lugar de disparadores, vistas materializadas o disparadores MySQL.
Es mejor utilizar una herramienta como Flyway para automatizar el proceso de migración de esquemas.
Déjame responder haciéndote una pregunta: si quieres construir una casa, ¿la construirás primero y luego harás un plano o primero harás planes? 🙂
El desarrollo de software se trata de reducir gradualmente el abstracción. Comenzamos con una idea de proyecto muy abstracta, luego hacemos algunos requisitos (que claramente es un poco menos abstracto), luego la arquitectura, el diseño y finalmente llegan al nivel de codificación (la abstracción más baja)
El modelo de datos es el modelo en el nivel de abstracción más bajo posible (como directamente mapeable a DDL), por lo que esto es lo último que hará.
El modelo de clase de dominio es una abstracción superior de la base de datos. Incluso es una abstracción de la capa Hibernate, ya que también se basa en el nivel de implementación de la abstracción.
Entonces, primero definitivamente modelaría un dominio usando clases y todo el poder de OO. Intente hacer que la implementación sea un modelo de clase independiente. No asuma JAVA, Hibernate, DB, nada y concéntrese en la lógica de su dominio en su lugar. Haga una especie de modelo de dominio “utópico”, clases de dominio lógicamente estructuradas perfectamente.
Luego, derive tanto la capa Hibernate como la propia base de datos de este modelo, usando las conversiones correspondientes.
Independientemente de la tecnología que esté utilizando, siempre debe ir “la verdad primero”. ¿Dónde está la verdad en una interfaz XML? En su especificación XSD, no algunas clases de implementación en ningún lenguaje arbitrario. Asimismo, ¿dónde está la verdad al interactuar con un RDBMS? Está en la base de datos, escrito en forma de DDL. La base de datos debe “poseer” su esquema, no generarlo a partir de alguna representación de cliente derivada. He escrito sobre este tema aquí.
Esta es la única forma razonable de mantener el control del esquema de su base de datos en el idioma que le importa a la base de datos. Esta es también la única forma de razonablemente:
- Evolucione el esquema una vez que entre en funcionamiento y no puede simplemente soltarlo y volver a crearlo
- Mantenga el control del rendimiento de la base de datos, especialmente cuando escribe consultas SQL en lugar de usar el ORM para navegar por sus entidades.
Tenemos la intención de usar un ORM (casi con certeza Hibernate) para mapear tablas a clases de Java. Su comentario fue que un enfoque de “base de datos primero” excluiría el uso de buenas técnicas de OO como la herencia.
Debería preguntarse por qué necesita la herencia en primer lugar. Dado que está almacenando sus datos usando el modelo relacional, debe usar las características de modelado del modelo relacional, y todas las representaciones del cliente (por ejemplo, su ORM) deben derivarse de eso. En casos muy raros, la herencia es incluso una técnica de modelado viable en esta área, y en su mayoría todavía no funciona bien, porque después de más de 20 años de OO, la gente ha llegado a la conclusión de que la herencia se usó en exceso en los primeros días de OO, especialmente la herencia. de estructuras de datos. Se debe favorecer la composición y, de todos modos, es más relacional.
Lo más probable es que su modelo relacional sobreviva a la representación de su cliente OO y debe asegurarse de que el modelo relacional sea sólido y normalizado, etc.
Este parece un buen punto, pero me pregunto si existen limitaciones. Si comenzara desde cero con un diagrama de clases en lugar de un diagrama de modelo de datos, ¿habría alguna manera de incluir todas las anotaciones, configuraciones, etc. de Hibernate necesarias en este modelo? Y si más tarde tuviera que modelar la funcionalidad específica de la base de datos, como restricciones, activadores, etc., ¿sería posible todo esto en el modelo dado que un diagrama de clases no está realmente dirigido a este tipo de cosas?
No creo que debas navegar por tu modelo de base de datos a través de un diagrama de clases derivado. Piense en términos de su ERD (que puede generar a partir de su DDL). La representación del ORM simplemente reflejará eso.