Someone suggested to me to use a table as described here in a project, and although I can’t say why, I don’t think it is a good idea.
MyTable (MyTableId PK, Type INT NOT NULL, MyForeignKey INT NOT NULL)
MyForeignKey can point to data in various tables depending on the value of Type. Of course, we cannot enforce FK integrity using such a model, but is this argument enough not to use it?
I’ll give you an example to where this could be used. Let’s say you have a Notes table in a system to save Notes about various objects; notes about Users, about Documents, etc. Normally, I would modelize this like this:
Notes (NoteId PK, Text VARCHAR(4000), UserId INT NULL, DocumentId INT NULL, …)
What my colleague proposes is to have such a table instead:
Notes (NoteId PK, Text VARCHAR(4000), ObjectType, ObjectId)
With the second implementation, ObjectType would tell us whether ObjectId is pointing to a row in the Users table or the Documents table. It has the advantage that the database structure and the code needs less modification if we want to add another type of objects.
What are the pros and cons of each solution?
Note: We will never have zillions of object types. It should remain below 10.
In fact our real life scenario is a bit more complex. It has to do with a permission system where Users may or may not have access to various types of objects (Documents, Notes, Events, etc.)
So for now in my database model, I have tables for these objects and additional tables to make relationship between them and users (UserDocuments, UserNotes, UserEvents, etc.) Permissions are set through Attributes in these link tables.
My colleague is proposing to have a single Permissions table instead like this
Permissions (PermissionId PK, UserId INT, ObjectType, ObjectId, … other permission fields…)
Is this a good idea?
Also, can we call this EAV or Open Schema? It is not exactly like what I have read on those topics.
Well, in my honest opinion bot solutions are correct, but for different purposes. As you mentioned number of such types counts, and this is usually the only thing that drives the decision.
I assume we are talking about OLTP system. So, if the number of types is relatively small, and you are sure it will not change (especially won’t grow up) you should choose the solution with separate columns for different types.
If the number of types is big (in my opinion 10 is already a big number) you should choose the solution with type and key column.
In general multicolumn variant is better, because you can use DBMS mechanisms to keep data integrity, wile when choosing type/key columns variant you have to develop those mechanisms on your own (i.e. triggers and procedures). Sometimes it is better to choose type/key column variant because the development and maintenance effort isn’t as big as structure change effort – if you don’t see any problems adding or removing FK columns to your tables during production use of your system you can still choose multicolumn variant (it is only a storage cost in that case).