Mysql log из 200 полей типа real

[danao]

Здравствуйте. стоит такая задача.
нужно регистрировать 200 показателей удаленного техпроцесса с периодичностью раз в секунду.
связь с тех процессом не всегда стабильна. по этому планируется на объекте создать буферную локальную базу в который будут складываться новые данные. При появлении связи данные передаются на сервер, переданные данные из локала удаляются.
Возникла дилемма. Насколько правильно будет создать таблицу из 201 поля.

 

[AnrDaemon]

Насколько правильно будет создать таблицу из 201 поля.

Только если ты уверен, что абсолютно все показатели взаимно релевантны на момент записи измерения.
И какая связь между буферизацией и структурой БД?

 

[danao]

не совсем понял про релевантность.Это лог, задержки в передаче даже на несколько часов не критичны. критичны пропуски в записи.
все 200 параметров считываются из источника одновременно и утверждается что на этот момент они все верны. В локальную базу попадают одним запросом.

просто при изучении вопроса столкнулся с устойчивым мнением что много полей это плохо.

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

про буферизацию это для полноты картины.

 

[Adelf]

если не будет поисков по всем этим полям, то можно все в одно текстовое поле писать.
время, поле со всеми данными
Тут надо знать как будут использоваться эти значения. Вот на что надо ориентироваться при проектировании структуры.

 

[danao]

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

 

[Adelf]

ну тогда на главной базе придется делать все поля. А вот на локальной можно и скопом хранить, но проще наверно также как и на главной. это уж up to you.

А хотя не. Там важно только если фильтр по этим полям есть. Можно будет фильтровать?

 

[danao]

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

 

[AnrDaemon]

все 200 параметров считываются из источника одновременно и утверждается что на этот момент они все верны.

Тогда просто сохраняй блоб с результатами измерения в одно поле. Если с локальной БД работает только буфер, нет никакой разницы, как этот буфер что-то хранит. Главное, что хранит.

А для общего развития на тему доставки логов советую любопытную статейку http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html

максимум что с данными внутри полей нужно будет делать по мимо диаграммы

Мы сейчас говорим о БД буфера или о конечной точке доставки данных?…

 

[danao]

Тогда просто сохраняй блоб с результатами измерения в одно поле. Если с локальной БД работает только буфер, нет никакой разницы, как этот буфер что-то хранит. Главное, что хранит.

да дался вам этот буфер. я же говорю просто для полноты картины.

Мы сейчас говорим о БД буфера или о конечной точке доставки данных?…

конечно же о конечной базе. я же писал что буфер освобождается сразу после отправки.

 

[Adelf]

в конечной базе наверно придется таки держать 200 полей. судя по всему ты ими хочешь вертеть туда-сюда и олапы разводить.

 

[AnrDaemon]

да дался вам этот буфер

Тогда не надо было о нём вообще писать, раз вопрос о нём не стоял.
Учитесь формулировать свои вопросы, иначе вам в программировании делать нечего.

 

[danao]

вопрос был сформулирован четко. Хранить все цифры в одной таблице или разбивать на группы. Описание ситуации в целом было дано чтобы предупредить тонну ненужного флуда.

 

[AnrDaemon]

В результате описание тонну этого самого флуда спровоцировало.
И стоило оно того?…

 

[Adelf]

Девочки, не ссорьтесь.
Закрою тему на всякий