I'm trying to figure out the best way to construct database tables to support what are, programmatically speaking, derived classes.
My base class will be "Request"
"OriginalRequest" & "AmendedRequest" both extend "Request".
"OriginalRequest" is a parent of "AmendedRequest" with a one-to-many relationship.
In constructing the database tables, given that "OriginalRequest" & "AmendedRequest" are only different by one attribute and their children are virtually identical, is it wise to build the tables as I have in the attached diagram, better to consolidate the requests and add fields to make it self-referencing to preserver the Original to Amended relationship or a different way all together?
Thanks in advance for your time & help.
Roughed out data model
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Sorry for the follow-up. Of course one can use OO Databases which were especially build for persistence of OO Data. Some databases like Oracle claim to support that, I can not say how true that really is.
There are quite a few OO Databases available
http://www.versant.com/en_
or http://www.progress.com/ob
Regards
Friedrich
Hi Friedrich,
I appreciate the input but the company runs on MSSQL so switching platforms isn't really feasible. We're building on .NET so there won't be any problem with handling the inheritance on the code side of things. I'm just trying to figure out the best way to structure the tables to represent the data relationships.
Sorry for not mentioning MSSQL, I'm looking for more generic "data architecture" help than anything. You're right about the OR Mappers we're considering using one in a future version but for the time being we're still trying to work up the table architecture so that if we need to access the data by any other means, the database architecture will be relatively sound.
Can you suggest anything from a database design standpoint as far as whether I should go with the current table structure or consolidate the 2 middle tables and make them self referencing?
Thanks again for your input!
Patterns similar to this have been described in OO pattern literature as History On Self (http://hillside.net/plop/
Both "Original Request" and "Amended Request" are historical versions of the same concept. In fact, given that their properties and relationships are identical (excepting the history property, previous number) I wouldn't think of them as two different classes but two related objects of the same Request class.
I've implemented something very similar to this before. We used the "self-referencing" option you spoke of in your question. We had both version number and modification date on each instance. While not quite as explicit it was easily understood and there was less effort in creating and evolving the table structures.
Regards,
Jim
You could look at the 3 ways that Hibernate does it:
* Table per class hierarchy (This is the least flexible method)
* Table per subclass
* Table per concrete class (I don't like this because it violates D.R.Y, but it does have it's place)
(They have variations on those but those are the 3 main ones)
http://simsonlive.wordpres
Since you are using .net it would be well worth the effort to look into
LINQ 2 SQL: http://msdn.microsoft.com/
LINQ 2 Entities: http://msdn.microsoft.com/
The latter being very similar to hibernate.
I would really advise you to look into a decent ORM layer.
We have used nHibernate in the past, but since LINQ to SQL/Entities is language integrated in .net, it makes more sense to use one of those.
Btw. A table per subclass is my preferred choice as it is flexible and it adheres to the D.R.Y principle.
That being said, keep in mind that it can cause performance problems when you have a large amount of subclasses. The excessive joining required can make queries slow and ugly (but that's always an issue when designing your DB, How much does one normalize a particular concept?.
Business Accounts
Answer for Membership
by: fridomPosted on 2009-02-26 at 00:31:50ID: 23742585
There exist databases which support inheritance. E.g PostgresSQL, that would be a good idea. The other is using some OR Mapper frameworks like e.g Rails which have support for inheritance in their "framework".
Regards
Friedrich