Say we have this scenario:
Artist ==< Album ==< Track //ie, One Artist can have many albums, and one album can have many tracks In this case, all 3 entities have basically the same fields:
- ID
- Name
- A foreign of the one-many relationship to the corresponding children (Artist to Album and Album to Track
A typical solution to the provided solution would be three tables, with the same fields (ArtistID, AlbumID etc…) and foreign key constraints in the one-many relationship field.
But, can we in this case, incorporate a form of inheritance to avoid the repetition of the same field ? I’m talking something of the sort:
Table: EntityType(EntityTypeID, EntityName) This table would hold 3 entities (1. Artist, 2. Album, 3. Track) Table: Entities(EntityID, Name, RelField, EntityTypeID) This table will hold the name of the entity (like the name of an artist for example), the one-many field (foreign-key of EntityID) and EntityTypeID holding 1 for Artist, 2 for Album and so on. What do you think about the above design? Does it make sense to incorporate ‘OOP concepts’ in this DB scenario?
And finally, would you prefer having the foreign-key constraints of the first scenario or the more generic (with the risk of linking an artist with a Track for example, since there is no check to see the inputter foreign-key value is really of an album) approach?
..btw, come to think of it, I think you can actually check if an inputted value of the RelField of an Artist corresponds to an Album, with triggers maybe?
I have recently seen this very idea of abstraction implemented consistenly, and the application and its database became a monster to maintain and troubleshoot. I will stay away from this technique. The simpler, the better, is my mantra.