2013-07-18 2 views
1

Требование: мы должны фиксировать данные за день в определенные интервалы времени (временной интервал является постоянным для набора данных). Интервал времени может составлять от 5 минут до 2 часов. Таким образом, количество точек данных за день может варьироваться от 12 до 288. Как мы должны проектировать нашу таблицу для учета этого варианта.Как создать таблицу для динамического числа столбцов?

Можем ли мы пойти с добавлением 288 столбцов в таблице? Если временной интервал составляет 5 минут, все 288 столбцов будут заняты. Если будет занято 2 часа, а не только 1-го 12 столбцов. и так далее.

+0

Какая СУБД вы используете? В Postgres вы можете использовать тип данных 'hstore' для преодоления ограничений шаблона EAV. –

+0

спасибо за ваш ответ ... в настоящее время мы используем postgres..but, db может быть перемещен в oracle или mysql на более позднем этапе. – adihere

ответ

2

Вы не хотите столбец 288.

Сложно спроектировать таблицу без концепции других таблиц вокруг нее, но в основном - иметь столбец для времени и добавлять другие времена. Если у вас есть время, связанное с объектом, добавьте внешний ключ к объекту, к которому он относится. Если вам нужны интервалы, а не время, когда вы можете иметь столбец «интервал», который просто отмечает с интервалом, в котором он входит.

"TimeOfEvent" 
    PK TimeofEventId 
    FK EventId 
    Interval 
    Timestamp 
+1

Итак, согласно этому подходу у нас будет запись 288rows за день. Поскольку нам нужно манипулировать данными 2months в случае, если это ухудшит производительность как на стороне базы данных, так и на стороне кодирования, где мы используем данные для получения некоторого результата – adihere

+0

Я понимаю, что вы говорите, и это мое мнение: на основе в вашем описании эта таблица будет содержать от 12 до 288 строк в день. Это много, но, по крайней мере, если в течение дня всего 12 интервалов - для сканирования требуется всего 12 строк данных. Если вы должны были создать 288 столбцов; Ваш запрос должен сканировать от 0 до 176 нулевых значений, чтобы получить нужные ему данные. –

+0

Кроме того, поскольку ваши наборы данных имеют согласованные интервалы времени; вы можете обойти мою точку сканирования 176 нулевых значений, указав, какие столбцы выбрать. Независимо от этого, я все еще думаю, что это плохая идея. Ваши инструкции SELECT могут быть очень длинными и трудными для управления, если вам нужно пройти через каждый сценарий 5 минут, 10 минут, 20 минут, дополнить и записать их. Я не верю, что использование таблицы TimeOfEvent приведет к пагубному влиянию на производительность при выборе каждого столбца (хотя я не мог этого гарантировать), и вы могли бы установить переменные в одном запросе для достижения разных результатов. –