Темата е може би или за раздел "Философия", или за "Академия", не знам.

Някой може ли да ме насочи (книжка, статия) за системи/подходи за структуриране на данни от измервания.
Идеята е от една страна данните да са "четими", за да не е необходим специфичен софтуер, за да се погледне набързо нещо, от друга страна да позволява организирането на нееднородни данни, който да могат лесно да се извличат от софтуер.
От трета страна да не се затруднява обратната съвместимост.

Така зададен въпросът звучи почти занаятчийски, но не е е насочен към имплементацията, а на по-организационно ниво.

едит: става дума за специфични измервания, които само в рамките на проекта могат да се променят неимоверно (като формат).

CSV? Не знам има ли нещо друго отговарящо на всички изисквания които си написал.

xml ?

json?

+1 чете се и се обработва с Ексел без проблеми

Благодаря за отговорите, но това са варианти за имплементиране.
В този смисъл може да се използва и rdb.
Ще опитам да дам пример:
Измерване на EIRP. Обикновено се прави като на централната честота в лентата се определи P1dB и тази мощност се използва за измерване в цялата лента. После се измерва затихването в канала (пак) на централната честота и следват няколко прости сметки. Това е най-простият вариант.
Какво правим обаче, когато P1dB го определим за няколко честоти в лентата и на всяка честота използваме различна мощност. Съответно и затихването в канала го измерваме за тези честоти. Това се прави, когато лентите са много широки и неравномерността в канала не е за пренебрегване.
Това е едно и също измерване, но по различен начин. Обработката на данните е подчинена на една и съща логика, протоколът от измерването изглежда по един и същи начин.

Аз винаги бягам от csv, защото не позволява толкова пригледно подреждане на данните, колкото на няколко листа в xlsx

Аз честно казано не мога в момента без да отделя ден-два за размисъл да ти хвана мисълта, но за твоята цел си има бази данни - въпросите са - как да си структурираш базата данни и каква точно платформа да избереш. Имам съвсем бегъл опит с такива неща, но като начало е много важно на точно каква платформа ще стъпиш. Аз примерно трябваше да трупам гигабайти данни в абсолютно линейна и двуизмерна структура и после сравнително лесно да се вадят отрязъци от данните. В крайна сметка за моите нужди най-удачна тогава се оказа Firebird. При теб най-вероятно няма да свърши работа. След като си структурираш правилно базата ти остава да си напишеш и правилно куеритата. Тогава един приятел програмист (ама истински програмист - от старото поколение) ми помагаше доста.

Бях почнал да пиша вчера, ама не довърших - има една "еретична" теория, че базите данни в текущия им вид са "кеш" на истинската информация - в смисъл че "истинската" информация са събитията, хванати с измерването. Нещо като протокола от лабораторното, в което е записан лог/журнал от проведените измервания. От този журнал винаги може да се извлече информацията, т.е. справка, независимо кой какво реши да иска, дори след години - т.е. без да има нужда да се повтаря измерването.
Тук да поясня че "събитие" е промяната в състоянието на нещо - например ако говорим за температурата на някакъв обект, то "събитията" там са точките, е който температурата е променила стойността си - като физически процес, който обаче не може да се хване с абсолютна точност като стойност и време при измерване - заради ограниченията на апаратурата. Но все пак математически можем да си представим процеса, и към него да насложим функцията на измерването (забавяне, шум, дискрети и тем подобни), които водят на изхода на тая функция да имаме подобен, но не толкова прецизен лог/журнал. Ако резултатът на изхода на тая функция не ни харесва сменяма оборудването с по-прецизно/бързо (скъпо) за да намалим разликите между реалния свят и записания лог.
Следващати стъпки подлагат тоя "лог" от събития на обработка - филтриране, забавяне (пак филтриране), ограничаване и т.н., което е вид компресия със загуба на информация. Един специфичен пример са аудио/видео кодировките/компресии. Което ни навежда на мисълта, че ако загуба е нежелана/недопустима, то "преработката" която цели намаляване на обема/трафика трябва да бъде някакъв вид компресия БЕЗ загуба на информацията. Т.е. нещо класическо и проверено математически, еле zip/LZMA или произволен друг алгоритъм. Ако това не стига трябва да се прави компромис - да се дефинира каква точно загуба е допустима и това да се докаже алгоритмично/математически че е вярно (да се валидира тая функция за "алтернативна" компресия). Искам да подчертая, че измислени идеи като "ще пиша по-рядко, то няма да се загуби кой знае колко", или други "занаятчиски" идеи са лишени от математическо доказателство и няма как да постигнат повече.
Тъй като ти говориш за разнородни измервания, трябва да погледнем какво идва рече "разнородни". Според мен имам предвид че мериш различни неща, т.е. състоянията на различни обекти - температура на водата, налягане на газовете, проводимост на почвата. Идеята е че първо трябва да се дефинира (опише, моделира) физическата величина, която ще мериш. След това обработката е една и съща - скаларната величина, която представя даденото състояние, се следи за изменение и това изменение се регистрира и записва.
В смисъла на лог това значи да имаш някаква дефиниция на времеви момент - някакво общовалидно време, което може да се съпостави с всяко измерване, т.е. всички уреди, които мерят, имат достъп до това общо време и могат да обвържат всяка промяна (измерване) с това време, т.е. да закачат таймстамп към него. После в един или много логове (няма значение, макар че е по-правилно да са разделени и после да се обединят чрез референция - демек линк, пойнтър) се намират събитията, като една от характеристиките е към какъв контекст (състояние) се отнася - примерно "таймстамп - идентификатор на обект - стойност". Идентификаторът на обект е линк (референция) към описанието, което пише че това е температура на пещ за агнета и т.н. - някакви описателни мета-данни, които могат пак да са съставени от референции. Например няколко различни реда в лога говорят за различни "обекти" - примерно една температура, едно налягане и една мощност, но всеки от тия трита обекта има референция към един и същи обект - географска локация на пицарията, където се мери това (както може и към три различни, или към 2, и т.н.)

Много омотано съм го описал, но толкова си мога. Можеш да видиш идеята на UML, или OPC UA за "моделиране" и "описване" на данни и връзки/отношения между тях.

Е не можа ли да не ползваш неща за ядене - както бях леко гладен, сега направо ми потекоха лигите... Иначе - подробно описание на база данни Само че в твоя случай се разчита да се хване "кога" е станала промяната и нейното цифрово изражение. Това само по себе си ще доведе до един вид "компресия" на данните. Това което аз правих беше логер с фиксирано време - на половин секунда се записват данните от 20 източника. За този случай Firebird си беше таман. За това което ти описваш е нещо друго - признавам си - не съм толкова навътре с базите данни, но поне знам че и такива има дето могат да го направят и по този начин, включително даже и с компресията на данните.

Има и такива бази - time series DB
Семплуването през определено време е нискочестотен филтър и маха по-бързите промени.

gicho добре го е описал. Когато ми се налага да пост-процесвам, т.е. имам необходимите ресурси като време и памет наливам всичко в nested dictionaries и обработвам с питона. Ако ми трябва съвместимост прехвърлям в json, а ако ми трябва достъп до по-усукани библиотеки минавам на pandas. Това е като за ежедневна работа. Ако се гони малък memory footprint или малко MIPS си трябват къстъм решения на ниско ниво, но това е друга бира.

Във класическите бази - напр. MySQL може да се зададат constraints. и там да се правят такива и всякакви други проверки и последващи действия, вкл. неочаквани стойности. Свободен софтуер без нужда от писане на друг.