I'm currently in a discussion with a co-worker regarding how to implement inheritance in a database. Yes...I know that databases don't directly support inheritance, but there are some common patterns to how this can be handled.
Martin Fowler talks about the three major database inheritance patterns…
Single Table: http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html
Class Table: http://www.martinfowler.com/eaaCatalog/classTableInheritance.html
Concrete Table: http://www.martinfowler.com/eaaCatalog/concreteTableInheritance.html
The way we have it implemented now is using the concrete table method. I have to admit I am more of an advocate of the class level method. I know the CRUD methods are a bit more complex, but I believe it pays some better dividends in the realm of maintenance as well as the model being more straight forward. The two main maintenance items I’m talking about are that if any of the common fields change, then you have multiple tables to modify as well as the DAO and DTO objects to update. The biggest item, however, is enforcing database relationships. We have other tables that reference back to the main identifier – if they are separated into different tables, then there is no way to enforce that relationship. It will also make the logic behind those interactions more complex as well - not to mention the queries to support the reports that will need to be generated from the data.
Anyone else have any other comments - I'd love to hear them!
0 comments:
Post a Comment