Question

We have a relational database (MySql) with a table that stores “Whatever”. This table has many fields that store properties of different (logical and data-) types. The request is that another 150 new, unrelated properties are to be added.

We certainly do not want to add 150 new columns. I see two other options:

1. Add a simple key-value table (ID, FK_Whatever, Key, Value and maybe Type) where *FK_Whatever* references the Whatever ID and Key would be the name of the property. Querying with JOIN would work.
2. Add a large text field to the Whatever table and serialize the 150 new properties into it (as Xml, maybe). That would, in a way, be the NoSql way of storing data. Querying those fields would mean implementing some smart full text statements.

Type safety is lost in both cases, but we don’t really need that anyway.

I have a feeling that there is a smarter solution to this common problem (we cannot move to a NoSql database for various reasons). Does anyone have a hint?

Answer 1

In an earlier project where we needed to store arbitrary extended attributes for a business object, we created an extended schema as follows:

CREATE TABLE ext_fields
{
    systemId INT,
    fieldId  INT,
    dataType INT // represented using an enum at the application layer.

    // Other attributes.
}

CREATE TABLE request_ext
{
    systemId   INT,  // Composite Primary Key in the business object table.
    requestId  INT,  // Composite Primary Key in the business object table.
    fieldId    INT,
    boolean_value BIT,
    integer_value INT,
    double_value  REAL,
    string_value  NVARCHAR(256),
    text_value    NVARCHAR(MAX),
}

A given record will have only of the _value columns set based on the data type of the field as defined in the ext_fields table. This allowed us to not lose the type of the field and it’s value and worked pretty well in utilizing all the filtering methods provided by the DBMS for those data types.

My two cents!