How to implement a super class, sub class relationship in the database?
If I have a class called animal, dog and fish is the subclass. The animal have attribute called "color". Dog have the attribute called "tail length", and the fish don't have this attribute. Fish have the attribute called "weight", the dog don't have this attribute.
So, I want to design a database to store this information. What should I do? Here is some ideas:
Idea 1: Making an animal table, and the table have type, to find what kind of animal, if it is a dog, just get the result from dog table.
Animal: color:String type:int
Type: Dog:0 Fish:1
Dog: TailLength:int
Fish: Weight:int
Idea 2: Store only Dog table and Fish table in the database, remove the animal table.
Dog: Color: String TailLength: int
Fish: Color: String Weight: int
Answer
The two approaches you mentioned:
- One table representing objects in the entire inheritance hierarchy, with all the columns you'd need for the entire hierarchy plus a "type" column to tell you which subclass a particular object is.
- One table for each concrete class in your inheritance hierarchy, with duplicated schema.
can be supplemented by two others:
- One table for each class in your inheritance hierarchy – you now have an Animal table, and subclasses have tables with foreign keys that point to the common set of data in Animal.
- Generic schema – have a table to store objects, and an attribute table to support any set of attributes attached to that object.
Each approach has pros and cons. There's a good rundown of them here:
Also take a look at these SO topics:
- Something like inheritance in database design
- Help me to connect inheritance and relational concepts
- Object-oriented-like structures in relational databases
- How to do Inheritance Modeling in Relational Databases?
- How do you effectively model inheritance in a database?
Finally, it should be noted that there are object-oriented databases (aka object databases, or OODBMSes) out there that represent objects more naturally in the database, and could easily solve this problem, though I don't think they're as frequently used in the industry. Here are some links that describe such DBs as compared to relational (and other) DBs, though they won't give you an entirely objective (heh) view on the matter: