Question

I’ll design and implement database for data acquisition and started to wonder what might be the best relational database structure for multivariable solution. There can be dozens of variables (configurable), different types (boolean, integer, float at least, maybe string). Values of different variables are not related. I need to store variable, new value and timestamp. Storing variables is triggered either by a clock or change of value.

Simplest solution would be one table with variable FK, new value, and timestamp, but since variables can have different types, type of new value causes problem. I can think few possible solutions, all involving separate table for variable definition and one or more table for timeseries, one record for each variable-value-timestamp:

1. Have some common data type which can store all values (string?)
2. Have multiple columns, one for each type
3. Have multiple tables for data values, one table for each type

Something else?

Basically I’m looking for good ‘database design pattern’.

Answer 1

The overhead of the database call swamps any overhead of parsing a number/boolean from a string. You might want to add a column for type (1 = Int, 2 = Dbl, 3 = String, 4 = Bool, 5 = date, etc) so that your code can select the correct action to take on the string encoded value in the database. Something like (off the top of my head):

create table foo_values (   -- optional fkey to select which foo this key/value belongs to   foo_uid number(18,0) not null enable,   key nvarchar2(64) not null enable,   -- could be a fkey to a table of types, or an enum, etc,    -- depending on database support     datatype number(2) not null enable,    value nvarchar(256)   created timestamp default systimestamp not null enable,    -- Foreign key and index stuff here, etc ... )