ВячеславЛ
А что Вы имеете в виду, под тем, что параметры будут отличаться своим местоположением?
Ну а так, ну и что что 140 полей и каждую секунду? Главное не вешать кластерный индекс. А ключ делать по той же секунде. Ну и озаботится поведением, если произойдет не корректная вставка одного параметра. То есть, если insert сбойнул, делать update каждого параметра в новой записи. А если нужен быстрый поиск, то можно таблицу секционировать. Плюс добавить ключ на году, месяцу, дню, часу и т.п. Как вариант - параметры хранить в одной колонке, со ссылкой на тип параметра и на таблицу с временем создания параметра.

ВячеславЛ,
paramid(int) objectid(int) интом не делайте. Я не соориентировался, что у Вас за СУБД, но думаю, типы данных short или подобные там есть. При таком объеме данных, нужно экономить каждый байт.

Уникальный ключ по paramid, objectid, date как я понимаю должен получиться, так что использовать key(int autoinc) смысла нет. Смертеподобно будет, если key окажется кластерным индексом.

ПыСЫ, насчет СУБД, надеюсь Вы не FoxPro или SQLite собираетесь использовать? Я боюсь они на такие объемы не потянут. Тут минимум MySQL нужен.

pectopatop
Имхо, все верно выше сказали - пишите тупо в текстовые файлики, зачем вам СУБД? Аналитику сложную делать ведь не будете?
Файлик, допустим, - каждый день новый.
Одна строка файлика - одно измерение (140 параметров).
Дневной файлик содержит 12млн строк, и имеет объем несколько десятков Мб - это не много (FAR, Total Commander спокойно ищут в нем текст за секунды).
Если вам это много - бейте на новые файлики допустим каждый час.
А может вообще лучше писцов посадить, что бы в ручную параметры переписывали? Гусиными перьями. Или на глиняных табличках. Что б уж наверняка никаких блокировок и лишних объемов данных? А СУБД это вообще от Лукавого, как и весь технический прогресс.
Dimitry SibiryakovТогда я бы делал по таблице на каждое сочетание paramid и objectid. То есть 140*5=700
таблиц. По-моему так серверу полегче будет на блокировках - быстродействие выше.
Хм. Мне какое то извращение в этой идее мерещится. Учитывая что пишется не 140 полей, а одно поле, то я не вижу причины особо беспокоиться о блокировках. 140 новых записей в секунду в одну таблицу, MS SQL вполне потянет. Уровень изоляции в транзакции только не делать высоким (смыла в данном случае в этом нет ни какого) . А то 700 таблиц, это тихий ужас при выборке данных будет, учитывая объемы. И, честно говоря, не уверен, что это увеличит быстродействие если на одной таблице использовать READ UNCOMMITED, что в данном случае, вполне допустимо.
Ну а поля paramid и objectid вполне можно заменить на одно поле типа smallint содержащие 700 вариантов значений.

Dimitry Sibiryakov,
На кой черт здесь id поля? Сделать составной ключ по дате и id параметров. При выборке сначала выбирать по дате. Плюс никто не отменял секционирование таблиц.

Dimitry Sibiryakov,
Ну увеличение индекса в три раза (а на самом деле в два, потому что поля paramid и objectid можно объединить в одно ), не так уж и страшно, по сравнению с появлением 700 новых индексов. Во вторых зачем нам бояться горячей точки если будет использоваться грязное чтение? Да и Вы думаете 700 новых таблиц горячие точки не дадут?

Dimitry Sibiryakov,
700 точек, каждая из которых в 700 раз холоднее (на практике не в 700, а в 600 где то за счет дополнительных полей) = одной точке которая в 700 раз горячее каждой. То есть вероятность то блокировки на каждой таблице в 700 раз меньше, но суммарная вероятность возникновения блокировки не меняется, это ж азы тервера.
Ну и на практике, вероятность блокировок реально возрастет.

Dimitry Sibiryakov,
С одной таблицей так же работает исключительно один писатель. Только в 700 раз чаще. Ну а дальше я уже объяснял.

Dimitry Sibiryakov,
А! То есть ты предлагаешь на каждый датчик делать отдельный клиент, который будет открывать коннект к БД? В такой ситуации, оно конечно может и лучше 700 таблиц. Можно вообще на каждый новый коннект новую таблицу создавать. Только, я, как сторонник традиционных видов секса, искренне полагаю, что в таких ситуациях, по умолчанию используется архитектура в которой основной клиент собирает данные со всех датчиков, а потом их отправляет на сервер. Тут вполне можно обойтись одним коннектом. Либо вообще, держать его открытым нон-стоп, либо пересоздавать по завершении транзакции.

Как то я двояко выразился. Я не намекал на ориентацию оппонента, а на то, что предпочитаю интимные отношения с людьми, а не с архитектурами систем.

Dimitry SibiryakovНу да, я предполагаю, что каждый датчик автономен и обладает собственным пунктом сбора
данных. Чтобы система не попала целиком под один медный таз.

Да Вы с ума сошли. 140 датчиков, под каждый из которых придется еще новую прошивку писать. Да и централизованная система попадет под медный таз, только в случае аппаратного сбоя. Проблемы возможного программного сбоя решаются стандартными средствами - транзакции, try{} и т.п. А в Вашем варианте, сбой одного узла будет сразу не очевиден, значит придется писать еще и ряд обработчиков которые будут реагировать на сбой узла. Нужно будет разрабатывать логику реагирования, анализ причин сбоя на каждый отдельный случай и т.д.
В общем старый добрый принцип Оккама - чем система проще, тем она надежней (в данной интерпретации), как никогда лучше подходит к моменту.

Dimitry Sibiryakov,
Ну так мы имеем 140 датчиков. Поэтому возвращаясь к тому, что я описывал прежде - 140 программ опрашивающих по одному датчику, согласно теории вероятностей на столько же ненадежны, как и одна программа опрашивающая 140 датчиков.