Подскажите оптимальную структуру базы данных

[olmi.little]

Подскажите оптимальную структуру базы для следующих данных данных: время | инструмент | страйк | цена.
Инструмент – это, например, газпром, нефть, золото. Страйк – это целочисленное число, которое характеризует инструмент, страйков может быть от 10 до N, где N – заранее неизвестно. Цена – это цена инструмента, типа float.
Простой вариант:
time | instr | strike1 | strike2 | strike3 | ... | strikeN | price
не подходит, т.к. количество страйков заранее не известно. Более того, в течение дня при заполнении БД используются только некоторые страйки. Вручную создавать дополнительное поле, когда появился дополнительный страйк – не вариант, т.к. не известно, будет ли нужно это поле в конкретный момент или нет.
Есть чуть более сложный вариант: во временную таблицу записывать те данные, которые есть; а к конце дня из этих данных формировать основную таблицу, и в этот момент создавать нужные поля для страйков.
Дополнительная проблема в том, что выборки из таблицы должны быть максимально быстрыми.
Какова наиболее оптимальная структура базы на ваш взгляд?

 

[ramses21]

Наверно для страйков надо делать отдельную таблицу с id, id_instr, value, time
Страйки можно привязать по айди к таблице с инструментами. Впрочем как обычно...

 

[olmi.little]

Проблема в том, что количество страйков не известно, и что каждый день используется только несколько страйков.
В вашем варианте в неиспользуемых полях будут дыры, что не очень хорошо; кроме того, у каждого инструмента свой набор страйков, поэтому нужно будет делать несколько дополнительных таблиц (одна таблица со страйками для газпрома, другая таблица со страйками для золота и т.п.), в итоге скорость запросов будет существенно снижаться.

 

[ramses21]

Отчего же дыры будут? Есть таблица инструментов газ, нефть, уголь и есть таблица страйков 5 штук связываем по айди к газу, 3 штуки к нефти и 15 штук к углю. Что тут еще думать? Одна таблица инструментов, одна таблица страйков. Между ними реляционные связи по айди.
А скорость запросов обычно снижается после 300к строк в таблице или от кривого запроса. В других случаях не особенно заметно вроде.

 

[olmi.little]

Количество страйков заранее неизвестно, их может становится больше, но их количество не может уменьшаться. И ещё у каждого инструмента страйки разные.
Запросов очень много, каждую секунду добавляется несколько записей (по одной записи для каждого инструмента). Поэтому данных очень-очень много и нужна самая оптимальная структура таблицы.
Всё равно спасибо за помощь!

 

[Андрей Шпак]

Секундочку! А время точно к инструменту, а не к страйку относится? Может так: есть есть таблица инструментов - строго ограниченная [instr] - id| name
и есть таблица [strike_events] : time|id_instr| strike_N | total
индексация по времени и инструмент ИД, может и по страйк_N. Ну и архивация дданных каждые .... Это - максимум по сскорости..