Reputation: 10247
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:
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?
Upvotes: 1
Views: 387
Reputation: 24134
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!
Upvotes: 3