• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate and database physical design

 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

All of a sudden, something interesting regarding the physical database design of a hibernate-driven application came to my mind and I just want to get your ideas and views on that. As a persistence layer, Hibernate provides an abstraction over the database and allows to define foreign key relationships and cascade database operations easily. Generally, when we design databases we create foreign key relationships and cascade modes on database tables themselves and map them in hibernate also. But if want, it is still possible to have hibernate mappings of foreign key relationships between entities and keep the database tables (physical database design) unlinked through foreign key constraints. If we do so, we come up with a physical database design where tables do not have any relationships between each other on the database table level. But through hibernate, we have defined the foreign key relationships and cascade levels properly resulting the data integrity that we expect to have.

I just want to know if it is ok to do so. Any problems in that approach? Do we really need to maintain the entity relationships at database table level?
Any ideas on that matter? Your responses are greatly appreciated.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When you say physical model do you really mean a logical model? A physical model is the model you provide that does all the database specific stuff (e.g. using an Oracle specific data type, or defining a SQL Server collation etc.). A logical model describes the entities and their relationship with each other in a database agnostic way.

Getting the logical model right is really important. You need to be able to trust the data obeys the rules you expect - this is one of the reasons you use a relational database, rather than simply using some amorphous data store. If you try to enforce relationships between entities using a client applciation you have to ensure that is the only application that connects to this database which is fairly limiting. Get the logical model right any everything else comes form tha, if you get it wrong you will be working round it (and cursing yourself!) for years to come.


 
Khp Virajith
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Paul,

Yes, I did really mean logical database design. Sorry for the mistake. The point you have highlighted is really important. If the application is one and only one application that goes to use that db, it does not make any problems. But, still there can be future possibilities to others system use the same database. In such a scenario, big problem might occur with respect to the data consistency.

Thank you very much for your response. greatly appreciated.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic