Разработка своего формата

gzipped xml | gzipped json | ... :)

> какие есть альтернативы?

Хранить данные в базе.

А может это проще в JSON хранить?

а заархивировать?

> однотипные строчки вида: <block time=«1000» size=«1000» offset=«0» marks=«» comment=«»/>, которых может быть тысячи.

В год будут записываться несколько тысяч новых файлов.
XML

Жесть как она есть, XXI век. А про базы данных вы слышали когда-нибудь?

Хранение хранением, хранить-то все равно в чем и как, особенно когда данные записываются относительно постепенно.

А как вы потом будете обращаться к этим данным? По каким критериям будет вестись отбор результатов?

велосипедеш?

Если уж какой-нибудь sqlite влом использовать, то хотя бы в обычные текстовые файлы сохраняйте, разделяя величины табами

Можешь перечислить преимущества своего формата перед whatever? Милый мой буратино.

> Жесть как она есть, XXI век. А про базы данных вы слышали когда-нибудь?

Идея насчет БД интересная. Ситуация такая: непосредственно данные (на файл) порядка 1-2Мб, аннотация порядка 100Кб (~5-10%). Нужно в одном файле хранить одновременно данные и аннотацию. По этой причине:

1) не выйдет ли так, что присобаченная к каждому файлу маленькая база данных будет занимать больше места, чем XML+табличка_с_разделителями_где_это_надо?

2) насколько в БД, которую вы можете предложить, удобно будет хранить древовидные структуры (которые так удобно хранить в XML).

Эээ... формат, я как понял, будет не мутированый xml, а просто своя структура данных в xml. Нет?

> Можешь перечислить преимущества своего формата перед whatever? Милый мой буратино.

1) Одновременно относительно удобно хранить как древовидные структуры, так и табличные данные.

2) Нет зависимости от специфических форматов (вроде БД sqlite), а парсеров XML сколько хочешь и они взаимозаменяемы.

3) Хоть XML и не является удобным человекочитаемым форматом. Однако я думаю, если потеряется вся документация на формат и все исходники программы (через нцать лет), то разобраться с XML будет проще, чем с любым бинарным форматом.

> вроде БД sqlite

Грязная пропретарная поделка!

С чего бы она проприетарной была?

> будет не мутированый xml, а просто своя структура данных в xml

Да конечно, это 100% валидный XML. Просто я хочу понять, насколько нормально в XML использовать таблицу с разделителями вместо забора из <block time=«1000» size=«1000» offset=«0» marks=«» comment=«»/>. И попутно интересуюсь насчет использования U+001F, U+001E для разделения в таблице.

> С чего бы она проприетарной была?

http://fc05.deviantart.net/fs71/f/2010/077/c/3/The_Sarcasm_Misunderstanding_b...

А зачем так страшно? Почему тупо не записать данные в определенной последовательности в файл?

> Грязная пропретарная поделка!

Да не что бы грязная или проприетарная, просто у меня нет уверенности, что через 10 лет текущий формат sqlite будет также легко читаться как и сейчас. А у вас есть?

Сначала аннотацию в xml, затем данные в тот же файл через пробел или еще как. Или отдельно аннотацию в файл.xml а данные в файл.dat

Или еще как... 100500 вариантов.

БД имеют как свои плюсы так и минусы, от задачи зависит. Мы напр. на файлах все держим.

Смахивает на неудачный выбор инструмента.

man sqlite, mongodb, json, bson

Спасибо, поржал.

А когда вы через 2 года захотите формат аннотаций сменить, будет тоже очень ржачно :) . Google protobuff в помощь.

БД во все поля. SQL/NoSQL/whatever.

данным, которые получены с экспериментальной установки

Почему их тоже не хранить в БД?

А что, сложно будет потратить несколько минут и преобразовать формат?

> А у вас есть?

Да.

> БД во все поля. SQL/NoSQL/whatever.

задачи разные бывают. У нас с одного расчета валится дцать Гб бинарных данных, диск чуть успевает писать. Как это в БД сувать и зачем? А если сувать в БД только аннотации, как потом следить за целостностью данных?

Сарказм - это не шутка.

> БД во все поля. SQL/NoSQL/whatever.

Относительно реляционных СУБД (в лице sqlite, по крайней мере) я уже говорил: http://www.linux.org.ru/jump-message.jsp?msgid=6361354&cid=6361773

1) Насколько много маленьких БД лучше чем много маленьких XML по объему и скорости доступа? Слить все в одну большую БД не представляется возможным.

2) Будет ли удобней в БД хранить множество разнообразных мелких древовидных структур?

А когда вы через 2 года захотите формат аннотаций сменить, будет тоже очень ржачно :) . Google protobuff в помощь.

А вот можно поподробнее про то как Protobuf поможет в случае изменения формата? На примере:

struct Foo
{
  P1 p1;
  P2 p2;
  P3 p3;
};

разделяется на

struct Bar
{
  P1 p1;
  P4 p4; // для этого есть некоторое разумное значение по умолчанию
};

struct Quux
{
  P2 p2;
  P3 p3;
};

Protobuf мне поможет сделать такое преобразование формата?

Будет ли удобней в БД хранить множество разнообразных мелких древовидных структур?

Не в реляционной СУБД.

только yaml

а вообще нафуа тебе свой формат, бери hdf и вперёд

> Не в реляционной СУБД.

А будет ли в не реляционной СУБД удобно хранить таблицы?

Вопрос ко всем: почему мой формат хороший я попытался сформулировать. А почему он плохой?

P.S. Слово «формат» похоже что не самое лучшее. Скорей это лучше назвать «XML-based language» с определенными соглашениями... На идею этого формата меня натолкнул svg. В котором координаты точек хранятся не в виде <point><x>10</x><y>10</y></point>, а просто через пробел идут числа. Можно считать, что у меня что-то наподобие...

Поможет. http://code.google.com/intl/ru/apis/protocolbuffers/docs/proto.html#updating

> А будет ли в не реляционной СУБД удобно хранить таблицы?

Если по ним не надо делать выборку, значит это не таблица, а просто надор данных. Например,хеш или массив, которые можно сериализовать.

В базах типа монги можно любые структуры хранить. Но для вас это может быть overkill. Определитесь сначала, как вы данные извлекать будете. Может вам вообще BSON-а выше крыши будет.

А почему он плохой?

Потому что вы свалили в кучу структурирование данных и оптимизацию, которая нарушает структуру. Причем корежить структуру начали до того, как с ней определились. А, да, еще способ хранения раньше времени привернули, и не факт что удачный.

>Просто я хочу понять, насколько нормально в XML использовать таблицу с разделителями вместо забора из <block time=«1000» size=«1000» offset=«0» marks=«» comment=«»/>

Это не Ъ, но когда нельзя но очень хочется, то можно. Плюс, не пиши пустые атрибуты и те, что имеют дефолтное значение (0, например).

Я, анверно непонятно выразился. Пусть в версии 1 есть структура, все поля которой обязательны

struct Foo
{
  P1 p1;
  P2 p2;
  P3 p3;
};

Я хочу версии 2 заменить её парой структур:

struct Bar
{
  P1 p1;
  P4 p4;
};

struct Quux
{
  P2 p2;
  P3 p3;
};

В версии 2 все поля обеих структур также являются обязательными, но при преобразовании мы можем для поля Bar::p4 задать некоторое разумное значение. В документации на Protobuf указано, что может быть удалено только не required поле, а новые поля должны быть либо optional, либо repeated.

Если поле Bar::p4 я могу трактовать как необязательное, но я не могу этого сделать для остальных полей при начальной разработке. Protobuf позволяет обспечить совместимость при простом добавлении или удалении старых необязательных полей. В случае больших изменений в структурах, он не поможет автоматизировать преобразование.

Может быть подойдет berkeley db xml?

Thrift/Protobuf

XML нынче не в моде.

> Если по ним не надо делать выборку, значит это не таблица, а просто надор данных.

Пардон :) я имею ввиду, то что называется «two-dimensional arrays of data» :)

Но я все равно не понимаю почему запихнуть этот «массив» в BSON это круто, а разместить числа через пробел где-то между «тегами» <foo> и </foo> это полный отстой.

данные, с установки... А туплы на что?!? Иди на http://root.cern.ch/

Вы неправильно ставите вопрос. Запихнуть в любой структурированный формат круче, чем изобретать свой лисапед с пробелами и табуляторами.

Не-не-не. Рассмотрим конкретно мой случай.

Структурированный формат: ключ-значение. Например: <block time=«1000» size=«1000» offset=«0» marks=«» comment=«»/> Структурированный формат? Однозначно.

Теперь по образу и подобию запишем это на BSON. Какие преимущества это даст? Меньше будет занимать памяти (в разы)? Я сомневаюсь. А ради этого все и затевалось.

С другой стороны, названия ключей занимаю столько же памяти сколько и сами значения (а может и больше). Другой вариант: записать только значения, и договориться, что первое значение это time, второе size, третье offset и т.д.

А теперь главный вопрос: В чем принципиальная разница между: бинарным массивом значений BSON+соглашением какой элемент массива чем является и XML+пробелы и табуляторы+соглашением какой элемент чем является? Лапша она как была лапшой, так лапшой и осталась в независимости текст это с пробелами и табуляторами или Ъ бинарный формат. Я наверное нетрадиционный или еще хуже — гуманитарий :(, ну не понимаю я принципиальной разницы! Вот между форматом ключ-значение и массивом значений понимаю, а тут нет. Разве только что велосипедизма меньше, но оно того не стоит из-за человекоНЕчитаемости BSON.

Возникла проблема: файлы получаются слишком большими, в них 98% составляют однотипные строчки вида: <block time=«1000» size=«1000» offset=«0» marks=«» comment=«»/>,

смотрим что получится при использовании yaml:

---
[ 
  {block time: 1000, size: 1000, offset: 0},
  {block time: 1000, size: 1100, offset: 0, comment: my evil comment}
  # whatever so ever
]
...  

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

получился большой размер? проходим libgzip, и вуаля

да, если, например, в группе параметров изменается только один, можно записать так, например:

---
- {block time: 1000, size: [1000, 1100, 1200], offset: 0}
- {block time: 2000, size: 1100, offset: 1, comment: my evil comment}
# whatever so ever
...

PS чёрточки в начале каждой строки аналог квадратных скобочек из первого примера (альтернативный вид записи)

Ок, мотивация понятна. Каков будет объем записей и нужен ли будет произвольный доступ и если да, то как планируешь его осуществлять?

Повторяю - ваша кривулина называется XML по недоразумению. Стандартным парсером ваши табуляции до значений не раскручиваются. Вот когда каждое значение в тег обернете и опишете грамотно - поймете, в чем разница с bson.

s-expression спасут мир от нового формата!!

А если обеспечить совместимость с Common Lisp то можно вообще сэкономить на парсере ;-)

> s-expression спасут мир

Чем они лучше xml?

можно вообще сэкономить на парсере

Парсер xml не сказать, что бы редкость, так что особого профита от экономии не видно.

> В котором координаты точек хранятся не в виде <point><x>10</x>

<y>10</y></point>

Самый большой профит от использования XML это возможность использования технологий типа XPath/XQuery/XSLT, отказываясь от подобного способа структурирования информации

просто через пробел идут числа

вы в значительной степени нивелирует данные возможности.

не выйдет ли так, что присобаченная к каждому файлу маленькая база данных будет занимать больше места, чем XML+табличка_с_разделителями_где_это_надо?

Не будет. Используй SQLite для нативного кода, H2 для Java, или эээ, ну наверное тоже тот унылый клиентик к SQLite для .NET

насколько в БД, которую вы можете предложить, удобно будет хранить древовидные структуры (которые так удобно хранить в XML).

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