I'm moving this question for StackOverflow in hopes to get perspective from a more database-oriented community.
Here is a basic representation of what I'm doing (in pseudo sql):
Parties
- ID, AUTO_INCREMENT
- Type
- Shared_Data
- Primary Key (ID, Type)
User_Sub
- ID
- Type, Default 'U'
- User_Data
- Primary Key (ID, Type)
- Foreign Key 'User-Party' (ID, Type) references (Parties.ID, Parties.Type)
Organization_Sub
- ID
- Type, Default 'O'
- Organization_Data
- Primary Key (ID, Type)
- Foreign Key 'Organization-Party' (ID, Type) references (Parties.ID, Parties.Type)
Because data is spread across multiple tables, I'd like to be able to read from and insert into the parent and child tables at once. Reading is fine, and can be done with a:
CREATE VIEW Users as
SELECT P.*, U.User_Data FROM Parties P
Inner Join Users_Sub U on P.id=U.id, P.type=U.type
Inserting, though, is more difficult.
- I can do two consecutive queries: One into the parties table, then one into a sub table.
- I can create a stored procedure in order to perform multiple queries in one transaction.
- This answer mentioned moving columns into the super table and using a trigger after insert on the super table to insert into the sub table.
It seems to me that it might be more fitting to consolidate these sub-table columns back into the super-table and get rid of the sub-tables entirely. Since I'd probably need to join or union all of the subtables if I wanted to query values from the parties table anyway.
Is this generally how it is done in practice? There will be many unused columns if this is the case, and it will be difficult (though not impossible with triggers) to enforce 'not null' constraints. The case above shows only two sub table types – as the number of sub-types increase, the super table will become more bloated.
Any thoughts or suggestions on this would be much appreciated.
Best Answer
How about another answer? Get rid of the Party table entirely. I'm a passionate hater of the Party model as it causes vastly more problems than it solves.
However, since it's unlikely you're in the position to do such a thing:
There's nothing per-se wrong with this as long as you do your transaction control in your app. It's not what I would suggest though.
This is nasty from a model perspective. If you go this route you have attributes that apply only to organizations intermingled with attributes that are only for users. It becomes quite a mess and you just 'have to know' what is right and wrong. It is a significant impediment to clarity.
This is your best option. It maintains atomicity while at the same time encapsulating and decoupling the data access from your app. Do this.
UPDATED:
To clarify my point about the Party model. The following are my major beefs with the approach: