*
The moose likes JDBC and the fly likes ORM and Antipatterns Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "ORM and Antipatterns" Watch "ORM and Antipatterns" New topic
Author

ORM and Antipatterns

Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

Hi Bill,

Does using an ORM such as Hibernate encourage the use of antipatterns? Or does the object oriented query approach helps reduce the number of antipatterns?

Kind regards,
Wouter


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Bill Karwin
author
Ranch Hand

Joined: Aug 02, 2010
Posts: 32
Hi Wouter,

Keep in mind that the value of ORM tools is to improve developer productivity, not to produce good SQL code. In a project with budget or time constraints (same thing, really), the largest expense is paying developers' wages, so ORM tools are successful if they reduce development time. That's kind of orthogonal with respect to SQL antipatterns.

But I can think of at least one antipattern that Hibernate is guilty of: Polymorphic Associations. This encourages developers to design tables where a foreign key can reference any of several parent tables. But to achieve this, you have to forgo using a foreign key constraint to enforce the references. That should be a red flag right there that Polymorphic Associations violates database design principles.


Bill Karwin is the author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

Thank you for your fast response and taking the time to answer questions from us.

// Edit: typo
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Bill Karwin wrote:
But I can think of at least one antipattern that Hibernate is guilty of: Polymorphic Associations. This encourages developers to design tables where a foreign key can reference any of several parent tables. But to achieve this, you have to forgo using a foreign key constraint to enforce the references. That should be a red flag right there that Polymorphic Associations violates database design principles.


You can still use only one table to store all classes. A column is added that identifies the type and thus allows the foreign key to reference only one table and not many as is the case of one table per class.
Bill Karwin
author
Ranch Hand

Joined: Aug 02, 2010
Posts: 32
Gerardo Tasistro wrote:A column is added that identifies the type and thus allows the foreign key to reference only one table and not many as is the case of one table per class.


Yes, that's the common way to employ polymorphic associations: add another column for the "type" of entity you're referencing. For example:

The problem is that you can't declare a foreign key constraint to enforce referential integrity for polymorphic associations. A foreign key must reference exactly one parent table. So the only way to use polymorphic associations is to forgo referential integrity.

When we try to use an RDBMS in a way that makes it impossible to use a fundamental feature like referential integrity, this is a strong antipattern smell.
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Bill Karwin wrote:
Gerardo Tasistro wrote:A column is added that identifies the type and thus allows the foreign key to reference only one table and not many as is the case of one table per class.


Yes, that's the common way to employ polymorphic associations: add another column for the "type" of entity you're referencing. For example:

The problem is that you can't declare a foreign key constraint to enforce referential integrity for polymorphic associations.


Example of MySQL database structure generated by Hibernate for a polymorphic representation of discounts in an application. There are various types of discounts that are represented in one table. Thus allowing many classes to reside on the same table and be referenced.

Personally I'm no fan of one table per class approach due to the reasons you mention. But using polymorphism on one table is very viable without breaking constraints.


Bill Karwin
author
Ranch Hand

Joined: Aug 02, 2010
Posts: 32
I admit I may have misunderstood Hibernate, it appears that it transparently creates a table to serve as a supertype. Mea culpa!
http://docs.jboss.org/hibernate/stable/core/reference/en/html/inheritance.html

The antipattern is when a child table references several parent tables using a single foreign key column, but there is no table for the supertype common to all the parents. It's more common for programmers who use loosely typed languages like PHP or Ruby to try to use the foreign key in the spirit of "duck typing."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: ORM and Antipatterns