БД пока не выбрана, но скорее всего это будет MySQL или PostgreSQL.
Есть система мониторинга, которая опрашивает различные сетевые устройства, и пишет информацию по ним в базу, по которой строятся различные графики. Сейчас все пишется в кольцевую БД (RRD), есть желание перенести все в реляционную.
В чистом виде структура основной таблички очень простая:
ИмяТип данныхОписаниеidintPKsensor_idintFK на датчикclockdatetimeдата/время измеренияvaluenumber(8,4)Результат измеренияerrintЕсли при измерении были ошибки, то код ошибки
Но ожидается довольно большая нагрузка — несколько тысяч или десятков тысяч датчиков будут опрашиваться раз в минуту, результаты будут хранится за достаточно большой интервал (несколько лет). Поэтому хотелось бы сделать так, чтобы со временем не переделывать все заново.

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

1. Нужен ли мне id? Или вместо PK будет достаточно полей sensor_id,clock?


2. Разрешать ли null в полях value и err? Или лучше туда писать какие-то значения (например -1 и 0)?


3. Несколько смущает несбалансированность таблиц; в БД будет несколько таблиц с относительно малым числом строк и одна таблица с большим числом строк. Не будет ли с этим проблем?
Может быть лучше таблицу организовать по другому, примерно так — id, sensor_id, clock, value0, value1, value2, ..., value59 — где valueN — это результаты измерений за момент (clock + N минут)? Тут конечно сильно усложнится выборка и обновление данных, но зато сократится число строк.


4. Нужно предусмотреть, что через какое-то время (несколько лет) базу нужно будет чистить от старых данных. Как это сделать так, чтобы процедура не занимала несколько часов? Хотелось бы устаревшие данные не удалять безвозвратно, а переносить в архив (возможно с агрегацией и снижением точности, как это делается в кольцевых БД).

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Кот Матроскин, благодарю, все доступно объяснили.

Dimitry Sibiryakov, иногда нужно посмотреть информацию по прошлым периодам, с точностью хотя бы до часа. А в RRD они уже агрегировались по среднему за сутки.

MasterZivНа все эти вопросы может ответить только один человек -- ты. Кроме тебя самого это никто не знает.
Мне без разницы, как именно сделать. Но я подозреваю, что будет разница для БД.
Например мне откуда-то вспоминается, что наличие null в таблицах ухудшает производительность работы с таблицами и индексами.

MasterZivНа самом деле есть один маленький секрет, который на самом деле вовсе не секрет. При доступе по индексу производительность запроса пропорциональна log N, (N число строк в таблице). Поэтому что миллион строк в БД, что 100 миллионов -- всё равно.
Я как бы знаю, но это в теории. На практике у 100 миллионов записей индекс будет занимать большой объем и возможны всякие тормоза, связанные уже с конкретной реализацией СУБД; скажем индекс перестанет умещаться в страницу памяти или будет требоваться его реорганизация.