Question

I have a table in a DB (Postgres based), which acts like a superclass in object-oriented programming. It has a column ‘type’ which determines, which additional columns should be present in the table (sub-class properties). But I don’t want the table to include all possible columns (all properties of all possible types).

So I decided to make a table, containg the ‘key’ and ‘value’ columns (i.e. ‘filename’ = ‘/file’, or ‘some_value’ = ‘5’), which contain any possible property of the object, not included in the superclass table. And also made one related table to contain the available ‘key’ values.

But there is a problem with such architecture – the ‘value’ column should be of a string data type by default, to be able to contain anything. But I don’t think converting to and from strings is a good decision. What is the best way to bypass this limitation?

Answer 1

The design you’re experimenting with is a variation of Entity-Attribute-Value, and it comes with a whole lot of problems and inefficiencies. It’s not a good solution for what you’re doing, except as a last resort.

What could be a better solution is what fallen888 describes: create a ‘subtype’ table for each of your subtypes. This is okay if you have a finite number of subtypes, which sounds like what you have. Then your subtype-specific attributes can have data types, and also a NOT NULL constraint if appropriate, which is impossible if you use the EAV design.

One remaining weakness of the subtype-table design is that you can’t enforce that a row exists in the subtype table just because the main row in the superclass table says it should. But that’s a milder weakness than those introduced by the EAV design.

edit: Regarding your additional information about comments-to-any-entity, yes this is a pretty common pattern. Beware of a broken solution called ‘polymorphic association’ which is a technique many people use in this situation.