If I understand your question correctly you are looking to store, let's say, a Person
entity with Name
and DateOfBirth
attributes. You will also have an Employee
entity which is defined as everything a Person
has plus EmploymentNumber
plus DeskNumber
but doesn't have DateOfBirth
. I'm guessing you want to be able to add a column to a base type and automatically see it showing up in the sub-type(s), and sub-sub-type(s). In short you are looking for an object-oriented data store. RDBMSs in general are not will suited to deliver this featrure.
If you know what these differences are and they are stable, at least between schema relases, you can define a type/ sub-type model. The base table has the columns which are common to all types. It has a surrogate primary key. From there you define further tables, strictly adding columns as you go. The same ID is carried through this hierarchy. The case where you need to remove columns from one type to a descendant is handled by defining an abstract common ancestor and placing the removed column in one branch but not the other.
For my example above we would end up with these tables
Human
ID PrimaryKey
Name
Person
ID Primary key and also foreign key to Human.ID
DateOfBirth
Employee
ID Primary key and also foreign key to Human.ID
EmploymentNumber
DeskNumber
You could add an column to the base table (Human
) to indicate which of the sub-types any particular occurance writes to. I don't think that is necessary because the process which writes to this database has to know which type it is dealing with in order to capture the correct values. Even if that process dynamically builds its list of attributes by examining the DB, it has to know which ultimate sub-type it is looking for to bootstrap the process.
It is tempting to have, say, EmployeeID
and a separate foreign key HumanID
. This is unnecessary.
When retrieving values you will either be interested in a known occurrance of a sub-type or will be looking for all available values for an instance i.e. "Human 99 as Employee" or "All about occurrance 99". The former can be had by INNER JOIN
ing Employee
up to its ultimate ancestor using the defined keys. The latter by OUTER JOIN
ing all tables in the model.
If your attributes can vary at run time you will be forced into using some variant of an entity-attribute-value (EAV) model. This has been well documented in many, many blogs, papers, forums and SO questions. While being fractious, conceptually challenging and non-performant these models can be made to work (for an appropriate definiton of "work"). Your tables will be a lot like this:
ItemType
ItemTypeID primary key
Name
ParentTypeID fk to ItemTypeID
Attribute
AttributeID primarykey
Name
AddedOrDeletedInd
ItemTypeID fk to ItemTypeID
Item
ItemID
ItemTypeID fk to ItemTypeID
ParentItemID fk to ItemID
ItemValue
AttributeID fk to Attribute
ItemID fk to Item
Value
ItemValue.Value could be a catch-all varchar() column or you could have one for each datatype you want i.e. ValueInt, ValueDate, ValueChar etc. and and indicator in Attribute to say which is populated. As you can see reading any one item's full definition will require recursion through a tree. Good luck.