ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Воскресенье
24 ноября
1017259 Топик полностью
Связанные сообщения
SqlAsn.1CsvBerkeleydb
Вопрос в том, что первично. Если бинарные данные в текстовом файле (т.е. другие программы будут его осознанно использовать как т...2019-12-05
Если вкратце, то при выборе Btree в качестве метода хранения появляется возможность поиска по частичному ключу в сортированных д...2019-07-10
Истина в том, что не надо всякое дерьмище на уши развешивать и тут же в него уверовать как в абсолютную и единственную истину. Д...2019-01-17
[ASN.1] -> --> Сводный системный топик. Все стандарты (актуальные версии) внутри.2018-06-13
Битовые поля вообще за пределами одной архитектуры с одним компилятором использовать нельзя. Профессиональные решения -- опять ...2018-05-06
На компрессию ссылка не по теме. По сути ASN.1 это такая форма "бинарного XML". Когда данные передаются не неким блобом с неизве...2018-05-05
Не понял вопроса. Отвечаю. В ASN.1 и всех нижележащих форматах упаковки (PER/BER/...) подразумевается, что данные несут уже инфо...2018-05-04
fk0, легенда (10.07.2020 18:33, просмотров: 1032) ответил MBedder на Накидайте идей по оптимальному формату записи для системы сбора данных
В общем случае, если задача решается в лоб использованием SQL-базы данных, то её и нужно использовать. Будет проще во многом. Другое дело, что может получиться _сильно_ не оптимально и избыточно. В данном случае непонятно какие выборки из базы данных потом будут осуществляться. Если нужно просто разделить по источникам, то что мешает сразу писать в разные же файлы, и потом брать только нужные. А для передачи -- запаковать в зип. В случае SQL же, любая другая база данных 

или таблица получается одним правильно составленным запросом. Вообще SQL удобен тем, что его потом легко посмотреть в разных разрезах. Данные, когда есть неколько полей связанных с временной меткой, может быть проще писать в no-SQL базу, вроде BerkelyDB. И опять же можно просто в файл(ы), суть БД в том, что она позволяет потом быстро данные доставать по каким-то критериям. А если доставать не надо (считываются потом строго последовательно), то и БД не особо нужна. Если писать в файлы, то чтоб не нарываться на сложности с преобразованиями форматов и типов, проще текст в CSV или чём-то подобном. Потом из таких файлов вырезать колонки, например, можно простейшими средствами (awk, GNU textutils, sed, grep). Легко преобразовать в тот же SQL, легко импортировать в Excel. А оверхед от текста -- всего в два раза-то. Для простоты записывать изначально можно в файлы (бинарные, текстовые, какие угодно), потом в конце работы файлы уже трансформировать в SQL и загружать в базу. А из базы выгружать нужный срез. Отдельные вопрос, если формат записи может меняться во времени. Какие-то колонки пропадать, какие-то появляться. И нужно потом понимать в каком формате осуществлялась запись. Текстовы файл или CSV об этом предсталения не даёт. И тем более, если в файл пишутся разные сложные структуры (а не просто десяток разных колонок) и они ещё разные всё время. В таком случае нужна какая-то аннотация к данным. В SQL это решается раскладыванием по разным таблицам и связью ключём. В текст можно записать в JSON или XML, в бинарном виде -- ASN.1. Парсер в любом случае получается сложный.

[ZX]