Механизм сохранения/изменения иерархических структур данных

[jangle]

Кто нибудь сталкивался сохранением больших коллекций иерархических данных в файл? Не в БД, а просто в бинарный, или XML файл на диске. Естественно, с последующим восстановлением, всей структуры при загрузке обратно в грид.
Для примера скриншот такого иерархического грида:


Проще говоря, есть набор неких строк, которые могут быть родителями для связанных с ними данных. Глубина иерархии неограничена. В полях сетки могут содержаться текстовые, числовые и бинарные (картинки) данных.

Задача:

1. Сделать сохранения содержимого грида (включая картинки) в единый файл.

2. Сделать загрузку данных из файла в грид, с восстановлением всей иерархии данных.

Короче говоря, пытаюсь придумать механизм сохранения/загрузки данных. Пока, кроме рекурсивного обхода всех ячеек, и формирования некого сложного INI ничего не придумал. Но это очень медленный и сложный метод.

Может есть идеи, как решить такую задачу более эффективно?

[alibek]

Зачем заново изобретать XML?

[Хакер]

Решение проблемы (проблем подобного рода) состоит в отделении структуры от данных. Структуру храним отдельно, данные - отдельно.

INI, XML - хранят структуру вместе с данным, прямо в данных. Отсюда, данные надо разбирать и анализировать, вытаскивая из них структуру.

[alibek]

Хакер, не надо мешать все в кучу.
Если тебе нужен структурированный XML, то прикрути к нему схему, XSD.

[jangle]

Решение проблемы (проблем подобного рода) состоит в отделении структуры от данных. Структуру храним отдельно, данные - отдельно.

А есть примеры подобного отделения?

[Хакер]

alibek
Ты не понял смысла текста.

jangle
Ну, попробуем сделать.

[alibek]

http://en.wikipedia.org/wiki/XML_Schema

[Antonariy]

Решение проблемы (проблем подобного рода) состоит в отделении структуры от данных. Структуру храним отдельно, данные - отдельно.

INI, XML - хранят структуру вместе с данным, прямо в данных. Отсюда, данные надо разбирать и анализировать, вытаскивая из них структуру.

Не вижу проблемы, не вижу иной структуры, кроме дерева, не вижу смысла хранить что-то по отдельности.

[Хакер]

Вот дают, а.

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

Antonariy не видит никаких проблем (не хочет видеть, точнее), потому что невнимательно читает пост.

И оба хотят поспорить, позащищать любимый ими формат XML. Во-первых, дайте поговорить с автором и донести до него суть. Ваши взгляды по поводу XML я (мы) уже слышали. Во-вторых, для тех, кто ещё не до конца понял, что имеется ввиду под отделением структуры от данных:



Было:

Код: Выделить всё

Foo|Bar|Baz|Quux|VisualBasic

Стало:


FooBarBazQuuxVisualBasic

Во-втором случае
1) не надо производить 28 тупых медленных сравнений байта с 124.
2) В данных может сам по себе встречаться символ 124 ("|")

[jangle]

Не вижу проблемы, не вижу иной структуры, кроме дерева, не вижу смысла хранить что-то по отдельности.

При большом объеме данных которые загружаются в сетку не будет тормозов? XML - это же простой текст

[Antonariy]

Хакер
Этот пример я накропал всего за полчаса, а твоему "попробуем сделать" стукнуло более полусуток.

1) и 2) не имеют ни малейшего значения. Символ | - пример от балды, - я так отделил ячейки, потому что контрола аналогичного тому, что на скриншоте, у меня нет. У автора алгоритм сохранения строки будет сильно отличаться. Еще можно придраться к тому, что я не учел при сборе строки служебные символы <>& и т.п., но это не концептуальная проблема и не проблема вообще. Если нужно - можно учесть.

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

[Хакер]

Antonariy
Во-первых, попробуем сделать ещё не начиналось. Во-вторых, хватит приводить в качестве основного фактора - временной фактор. Дескать, быстро.

У нас на краю города возводят новостройки. Быстро, с применением новых технологий. Таджики строят. 9 этажки, и самая толстая стена в этом доме- всего лишь в два кирпича. Потом к тонкой стене приклеивается изовер (утеплитель) и всё это зашивается декоративными панелями. Выглядит красиво, сделано быстро (как ваши программы), и даже зимой тепло. Между тем, в одном из этих домов появилась 9 см. трещина. Потому что нарушили нормы, потому что не провели исследование состояния грунта. Потому что быстрее сделать надо было, чтобы отчитаться и набить карман.


1) и 2) имеют огромное значения. Хранить структуру данных в самих данных - тупо. Это значит, что всю это композицию нужно анализировать (текст - парсить), чтобы выделить из всей каши структуру и данные. Хранить данные в виде тексте - такой бред и глупость, как хранить текст в виде картинки (там даже разноцветными линиями можно нарисовать сложную древовидную (и не только) структуру, надо же, а?). Чтобы потом рендерить эту картинку при сохранении, а при чтении - распознавать текст и структуру (что более сложно). Что долго, ресурсоёмко и главное - абсолютно безполезно.

Я не смотрел твоё пример, я не знаю, что ты взял от балды. | я взял сам от балды. Замени | на <seperator> и посмотри, сколько лишних данных мы получим в первом представлении файла.

Еще можно придраться к тому, что я не учел при сборе строки служебные символы <>& и т.п., но это не концептуальная проблема и не проблема вообще. Если нужно - можно учесть.

Не можно, а нужно. Идея сохранения структуры данных как часть этих данных несёт ещё одну проблему - маркеры, которые служат для указания структуры нельзя будет отличить от аналогичных последовательностей в данных. (Кавычку (символ) в строке нельзя от маркера конца токена T_STRING при анализе кода. Поэтому её либо экранируют (как в си-подобных языках), либо удваивают (как в VB) -- та же проблема).

[Antonariy]

jangle
Самое узкое место - конвертация картинки в хекс. При уровне инициализации равном 7 (получается 109600 узлов), отключении хекса и замене тормозной конкатенации более быстрым методом, сохранение в файл заняло примерно 1 секунду (размер файла получился 6 466 459 байт). Загрузка данных обратно в дерево заняла 7 секунд, из них 2 секунды тратится на добавление узлов в тривью. Из оставшихся на парсинг текста MSXML потратил 1 секунду и перебор ветвей в свою очередь 4.
В общем чистых - 5 секунд. Есть с чем сравнивать более другие способы.

Быстро это или нет - решать тебе.

Я не смотрел твоё пример

Пастернака не читал, но не одобряю (с)

Не можно, а нужно.

А вот это решать опять таки не тебе, а автору. Может у него в тексте не встречаются спецсимволы.

[alibek]

Хакер, судя по всему ты ссылки не читал и сути XSD не понял.
XSD это и есть та метаструктура, описывающая правила построения структуры данных.
Но если ты желаешь в очередной раз изобретать велосипед, то я не против.

[Хакер]

Наоборот. Понял, и говорю, что XSD не может быть даже названо хоть каким-то шагом в пользу отделения структуры от даных. Кроме того, сама по себе схема записывается таким же образом и её саму надо парсить, что плохо.

[Antonariy]

Хранить структуру данных в самих данных - тупо.

Наоборот, в xml "данные" хранятся в "структуре", а не "структура" в "данных". Хранятся, уже привязанные к конкретному элементу структуры. В кавычки я эти слова взял потому, что граница между структурой и данными в xml чисто умозрительная.

Это значит, что всю это композицию нужно анализировать (текст - парсить), чтобы выделить из всей каши структуру и данные.

Любой формат, будь он с разделением структуры и данных, или без, нужно парсить. Для xml уже есть готовый шустрый парсер. 109600 элементов в секунду - не шутка.

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

Хранить данные в виде тексте - такой бред и глупость, как хранить текст в виде картинки

Но ведь никто не заставляет картинки тащить в хекс. Это лишь пример реализации в чистом xml. Можно все картинки свалить в бинарном виде в конец того же xml-файла, каждой ячейке приписать те же атрибуты-указатели (относительно начала бинарной каши), при восстановлении резать весь файл на две части, MSXML скармливать только текст-структуру, а картинки получать через CopyMemory.

[Хакер]

Наоборот, в xml "данные" хранятся в "структуре", а не "структура" в "данных". Хранятся, уже привязанные к конкретному элементу структуры. В кавычки я эти слова взял потому, что граница между структурой и данными в xml чисто умозрительная.

Без разницы. Главное, что в перемешку. А значит одно надо отделять от другого.

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

Конечно будет.

Но ведь никто не заставляет картинки тащить в хекс. Это лишь пример реализации в чистом xml. Можно все картинки свалить в бинарном виде в конец того же xml-файла, каждой ячейке приписать те же атрибуты-указатели (относительно начала бинарной каши), при восстановлении резать весь файл на две части, MSXML скармливать только текст-структуру, а картинки получать через CopyMemory.
Я, вобщем-то, не говорил о проблемности сохранения картинок (хотя и она есть), а о проблеме обязательности парсинга.

[Antonariy]

А значит одно надо отделять от другого.

Расшифруй сочетание "надо отделять". Если это означает "надо написать код, отделяющий в данном формате одно от другого", то не надо. MSXML это сам делает. Надо всего лишь получить у него результат отделения.

Конечно будет.

Не вижу кода, только трёп. Вопрос все еще открыт.

Я, вобщем-то, не говорил о проблемности сохранения картинок (хотя и она есть), а о проблеме обязательности парсинга.

Расшифруй слово "парсинг". Ибо, не побоюсь запостить баян,

Любой формат, будь он с разделением структуры и данных, или без, нужно парсить.

[HiSER]

Расшифруй слово "парсинг". Ибо, не побоюсь запостить баян

parsing - синтаксический анализ

[VVitafresh]

...хватит приводить в качестве основного фактора - временной фактор. Дескать, быстро.

У нас на краю города возводят новостройки. Быстро, с применением новых технологий. Таджики строят. 9 этажки, и самая толстая стена в этом доме- всего лишь в два кирпича. Потом к тонкой стене приклеивается изовер (утеплитель) и всё это зашивается декоративными панелями. Выглядит красиво, сделано быстро (как ваши программы), и даже зимой тепло. Между тем, в одном из этих домов появилась 9 см. трещина. Потому что нарушили нормы, потому что не провели исследование состояния грунта. Потому что быстрее сделать надо было, чтобы отчитаться и набить карман.

Хакер, мне очень понравилось твое живописное сравнение со строительством дома
Смутно помню анекдот на тему "Если бы программисты строили дом" (кстати, если у кого-то есть ссылочка на него -- скиньте плиз).

Но, как ни странно, идея быстрее сделать, отчитаться и набить карман мне тоже нравится. Программа -- не дом, людей не привалит.

ИМХО, главное -- реализовать функционал. Пусть даже реализация будет далеко не самой оптимальной, но если скорость/удобство работы удовлетворяет заказчика, то все останутся довольными. Заказчик программой, а программист звонкой монетой в кармане.

А еще мне нравится идея "Good enough software", которую исповедуют в Майкрософте (так утверждают некоторые), т.е. "вполне нормальный софт", пусть не идеальный, но работоспособный, функциональный и такой, который вовремя удовлетворяет потребности рынка и позволяет "снять сливки" с потенциальных покупателей. И для того, чтобы успеть вовремя и раньше конкурентов придется чем-то жертвовать.

Конечно, мы не в Майкрософте работаем, но все-таки приятней за тот же промежуток времени сделать две (неидеальные) программы и получить за обе вознаграждение, чем одну, но "идеальную". Хотя насчет "приятней" я, наверное, неправильно выразился, скорее "выгоднее с материальной точки зрения". Ну а программирование для души и "вылизывание" программы лучше отнести к разряду "хобби", а не к ремеслу программиста.

[jangle]

Кстати, никто не пробовал использовать для сохранения подобных данных, вложенные объекты PropertyBAG ? Парсинг здесь не нужен, можно сохранять любые бинарные данные, да и работает наверное побыстрее чем XML

[alibek]

Можно, конечно.
Но как ты будешь хранить иерархию? PropertyBag это плоский список.

[jangle]

Можно, конечно.
Но как ты будешь хранить иерархию? PropertyBag это плоский список.

Ну как я говорил, использовать вложенные PropertyBag. Это же просто строковые данные, а вся "черновая работа" по парсингу выполняется VB. Вот к приему способ сохранения иерархии:

Код: Выделить всё

Parent
  |
  -----------data_1
  |
  -----------data_2
  |
  -----------data_3

VB код:

Код: Выделить всё

Private Sub Form_Load()

Dim Child As New PropertyBag
Dim Parent As New PropertyBag
Dim ParentArray(100) As String

Child.WriteProperty "data_1", "1"
Child.WriteProperty "data_2", "2"
Child.WriteProperty "data_3", "3"

Parent.WriteProperty "Child", Child.Contents

ParentArray(1) = Parent.Contents

MsgBox Len(ParentArray(1))

End Sub


[Andrey Fedorov]

А вообще - то что приведено в начале на снимке спокойно сохранится в одной обычной табличке. Где хранить эту табличку - в MDB, DBF, XML или бинарнике - другой вопрос, но какие проблемы могут быть я не вижу...

[Хакер]

Сделал сохранялщик-загрузчик.

Подумал, что неплохо бы написать статью. Ушёл писать.

[jangle]

Вообще, можно сделать универсальный класс для сохранение/загрузки данных в хранилище. Именно для таких ситуаций. А исходник потом выложить в Кирпичи

[Antonariy]

А исходник потом выложить в Кирпичи

Вуаля.

[Хакер]

Antonariy
Я тебя вчера ждал, но ты так и не появился. Даже запрос на авторизацию в асю послал, но ты не авторизовал. Что-ж, ладно.

Во-первых, твой пример не работает, ищет msxml6 и не находит его. Можно ссылочку?

Во-вторых, предлагаю провести тест-сравнение:

Имеем класс CDoodah, у которого есть переменные свойства Foo (строка), Bar (строка), Quux (лонг). Это основные данные, которые хранится в объекте класса CDoodah. Также у класса есть свойство-коллекция Children, в которой хранятся ссылки на дочерние объекты, а также свойство-ссылка Parent, ссылающаяся на родительский CDoodah.

Также у этого класса есть методы AddChild и RemoveChild (понятно для чего, да?) но тебе они не пригодятся.

Твоя (или любого другого, кого заинтересует эта тема) задача - сделать функции LoadDoodahs и SaveDoodahs.

LoadDoodahs(ByVal sFileName As String) As Collection
Принимает путь к файлу, возвращает ссылку на коллекцию, в которой хранятся ссылки на top-level узлы дерева (в XML, если мне не изменяет память, такой узел должен быть только один. Пусть это будет <alldoodahs>, чтобы было справедливо).

SaveDoodahs(ByVal sFileName as string, ByVal ddd as collection)
Соответственно, принимает путь к файлу, и ссылку на коллекцию top-level дудахов, сохраняет все данные и иерархию в файл.

Важные моменты:

• Foo и Bar (свойства) должны сохраняться юникодными.
• Функции Load/Save должны быть максимально быстрыми. Потому как сравнивать будем потом в том числе и скорости.

Ы?

[VVitafresh]

Во-первых, твой пример не работает, ищет msxml6 и не находит его. Можно ссылочку?

Microsoft Core XML Services (MSXML) 6.0

[Antonariy]

Я тебя вчера ждал, но ты так и не появился. Даже запрос на авторизацию в асю послал, но ты не авторизовал.

Запросы на авторизацию я отвергаю без разборов, просто написал бы что-нибудь.

Во-первых, твой пример не работает, ищет msxml6 и не находит его.

Можно подключить любой msxml >= 3й версии.

Ы?

Ыгы
А пока что тынц.