Доброго времени суток!

Может кто сталкивался с подобным решением задачи и сможет прокомментировать потенциальные ошибки.

Есть некоторое количество источников данных (думаю цифра 200 на одну БД будет пиковой).
Источники однотипные, но типов есть несколько (образно - один дает A, B, C; другой только A, а третий E и D).
Есть режимы, в которых данные должны поступать каждую секунду. Запись не синхронизирована.

Есть идея, для оперативных архивов вести ряд таблиц с именем dev_ИД со структурой типа:
ДатаВремя , ТипЗаписи (секунда, минута ...), Далее поля типа INT и NUMBER соотвествующие конкретному типу устройства (в пределах 10-15 шт).
ДатаВремя+ТипЗаписи - primary key
Эти данные в принципе будут выбираться только запросами вида "ДатаВремя between ... and ТипЗаписи = ".
Запрашивать итоги и сложные join-запросы по этой таблице не планируется в принципе (интерес - отслеживать тенденции во времени и графики строить).

Обобщенные данные (часовые, суточные) пишутся в таблицу вида:
ДатаВремя , ТипЗаписи (секунда, минута ...), Источник (как в имени соответствующйе таблицы), Переменная (которую дает источник A, B, C...), значение .
Тут уникальный ключ на всё кроме "значение" и по индексу на каждый.
Данная таблица будет использоваться в конструкторах отчетов (диапазон запросов широк и многообразен).

Читающая нагрузка ожидается не очень большая. До 20 одновременно работающих, причем режим будет "сформировали табличку/картинку и 2 минуты изучаем)

Служебные таблицы (типа справочника источников, переменных, ограничений доступа....) подразумеваются, но не рассматривается, так как тривиально.

В общем лирический вопрос, можно ли так делать? ))

Заранее спасибо!

Dimitry SibiryakovДля первички за глаза хватит одной таблицы на все источники.


А не будет проблем при конкурентном доступе, когда все ломанутся писать?

SERG1257
Спасибо.
В таком направлении даже не думал.

Dimitry SibiryakovА это зависит от СУБД.


Postgre или MS если денег дадут.
Под одной таблицей для первички подразумевалась таблица вида:
Ключ1, Ключ2, ЗначениеА, ЗначениеБ, ЗначениеВ....
?


SERG1257

Хотя идея с текстовым логом мне уже тоже начинает нравится.
Если поднапрячься и сделать записи фиксированой длины по нему можно даже делать примитивный индексный поиск (естественно - каждому источнику по файлу). По сути даже отдельный демон не нужен, это может делать сам опросчик.
Единственное, что нужно будет это хороший RAID под такой сервер (или дублирующий сервер)...

Dimitry SibiryakovЧто за мазохизм - выбирать СУБД по которой у вас нет специалистов?..
Имелась в виду покупка ОC и СУБД.
Да и на этапе разработки всё равно кого-то привлекать прийдется, нельзя ж все дырки собой заткнуть )

Всем СПАСИБО за ответы/советы!

Будем думать!