Разработка базы данных для сбора данных с несколькими типами переменных

Question

Я спроектирую и внедрю базу данных для сбора данных и начал задумываться о том, какая может быть лучшая структура реляционной базы данных для решения с несколькими переменными. Может быть несколько десятков переменных (настраиваемых), разных типов (булево, целое число, по крайней мере, число с плавающей точкой, может быть строка). Значения разных переменных не связаны. Мне нужно хранить переменную, новое значение и метку времени. Хранение переменных запускается либо по часам, либо по изменению значения.

Простейшим решением будет одна таблица с переменной FK, новым значением и отметкой времени, но поскольку переменные могут иметь разные типы, тип нового значения вызывает проблемы. Я могу представить несколько возможных решений, все из которых включают отдельную таблицу для определения переменной и одну или несколько таблиц для временных рядов, одну запись для каждой переменной-значения-времени:

1. Имеют общий тип данных, который может хранить все значения (строка?)
2. иметь несколько столбцов, по одному для каждого типа
3. Наличие нескольких таблиц для значений данных, по одной таблице для каждого типа

Что-то еще?

В основном я ищу хороший "шаблон проектирования баз данных".

Answer 1

Издержки при вызове базы данных перекрывают любые издержки при разборе числа / логического значения из строки. Возможно, вы захотите добавить столбец для типа (1 = Int, 2 = Dbl, 3 = String, 4 = Bool, 5 = date и т. Д.), Чтобы ваш код мог выбрать правильное действие для выполнения закодированного в строке значения в база данных. Что-то вроде (от макушки):

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 ...
)

Answer 2

Попробуйте модель EAV (Entity-Attribute-Value) .