|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vitaly Lugovsky 2:5020/400 12 Mar 2002 19:35:22
To : "Evgenij M. Baldin"
Subject : Re: PostgreSQL тюнинг?
--------------------------------------------------------------------------------
Evgenij M. Baldin <baldin@slon.inp.nsk.su> wrote:
EMB> Конкретезирую - есть массив данных в 10 тыс. чисел - каждые n минут это
EMB> новый массив данных - то есть если использовать РБД, то это таблица, где
EMB> столбцы это каналы, а строки это время.
Почему это?!? Имеет место быть отношение ЧИСЛО-КАHАЛ-ВРЕМЯ.
Поскольку на одно время приходится много каналов (одновременно данные
снимаются, так?), то имеем две таблицы в 2HФ:
ЧИСЛО-КАHАЛ-RUN
RUN-ВРЕМЯ
А иначе это не РБД, а туплы какие-то блин CERNlib-овые... Кстати, даже
там никому в голову не приходит делать тупл в тыщу колонок. И, кстати,
именно подобное тупловое хранилище тут было бы куда как более уместно.
EMB> Можно конечно разбить эти 10 тыс
EMB> по разным таблицам, сделать многострочные калибровки, но это только
EMB> ухудшит текущее состояние.
Чаво?!?
EMB> это не справочник - это слепок системы на текущий момент, который имеет
EMB> дурную привычку со временем меняться временами очень не слабо, а что
EMB> самое неприятное никогда не знаешь зарание какой ,,слепок'' когда
EMB> пригодится. Таблицы- справочники тоже есть - там да, столбцов немного.
Если честно, я совсем не понял, зачем тут РБД. Проще много-много бинарных
файлов, по файлу на момент измерения. Ведь ключевой элемент тут только один,
время. Или всё же возможны хитрые запросы по измеренным значениям?
>> Я, собственно, и не собираюсь варганить это ни за какое время.
EMB> Я это понимаю :) - это варганю я - я прошу совета - то есть того, что
EMB> люди, как правило, не против дать :)
Всё ещё недостаточна постановка задачи. Какого вида запросы имеют место
быть над этими данными, зачем выбрана была RDBMS?
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
