Сохранение конфигураций, QSettings, XML, INI

[Zerkin]

Доброго времени суток, товарищи!

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

Особенности технического использования QSettings, или XML-[де]сериализации меня не интересуют, всё это неоднократно делалось. Мой вопрос, вероятно, касается больше проектирования, хотя черт знает.  Попробую объяснить задачу,  сильно не вдаваясь в специфику и подробности. Может быть, какая-то информация будет и лишняя.

Есть некоторая крупная программная среда, для обработки и анализа определенных данных. Эта среда содержит в себе множество разнообразных модулей и  инструментов для различной обработки/анализа. Работа в этой среде начинается с открытия проекта, а сам проект является некоторой древовидной структурой, элементы которой как раз могут быть подвержены какой-либо обработке или анализу, то есть являются входными данными для определенного инструмента/модуля (для упрощения скажу, что используется каждая вершина по одиночке). У каждой вершины этого дерева должен быть набор параметров, подлежащих сохранению между запусками среды (если мы конкретную вершины не удалим из дерева). То есть мне необходимо хранить N различных конфигураций и наборов параметров, где N - количество элементов дерева. Так же необходимо хранить параметры как для общей среды (этакий набор общих параметров системы), так и набор настроек для каждого инструмента.

Скорее всего, решение мне нужно только под винду.

Возникли следующие идеи:
1) QSettings. Засунуть в реестр параметры для общей системы еще можно, но уже начиная с  настроек для модулей и инструментов получаем проблемы, так как  все  они подключаемые/отключаемые, то есть набор инструментов может быть абсолютно разный у среды. А что касается настроек для узлов дерева так тем более, они вообще могут быть удалены, следовательно хранить ничего и не надо. Всё это держать в реестре абсолютно не логично.

2) XML. Сериализовывать в отдельные файлы общие настройки среды, настройки для каждого модуля. Для каждой вершины так же создавать свой xml-файл. Так как я делал конкретный модуль для среды, то этот подход мне знаком. Я как раз создавал собственную xml'ку для моего модуля. Но если посмотреть в масштабе, то возможное количество сгенерированных xml-файлов может быть очень велико, что так же не  есть хорошее решение.

3) QSettings с INI. Этот вариант мне нравится меньше всего, так как объемы информации для хранения могут быть достаточно велики. Создать .ini для общей системы опять же можно, но дальше... В принципе, это дублирование 1ого варианта, разве что более кроссплатформенно


Подытожив вышесказанное, мне в голову приходит только одно решение - для общих настроек среды использовать QSettings, а для всего остального XML.

Что вы можете сказать по этому поводу? Может быть, я чего-то не знаю, и такие вещи делаются как-то по-другому? Поделитесь опытом.

Спасибо.

[Vamireh]

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

[Bepec]

Радикальный вариант - БД

[Zerkin]

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

Ну древовидность проекта тут никакой роли не играет, опять же, для упрощения скажу, что каждый элемент дерева используем по отдельности, грубо говоря, каждый элемент - это отдельный проект, для которого нужно сохранять настройки и параметры. В комплексе с этим деревом работы никакой нет. То есть я не хочу привязывать иерархичность XML к иерархичности проекта. Всё отдельно - у каждого элемента своя информация для сериализации. Вообще зря я про древовидность проекта упоминул. Допустим, есть много элементов и у каждого свои независимые настройки.

Радикальный вариант - БД

Я бы не сказал, что совсем радикальный =) Вероятно, нужна как раз таки БД , но не в классическом своём понимании.  Хочется иметь какие-то классы, обеспечивающие полноценную работу со всей этой информацией как с определенной базой.

Значит возвращаемся к вопросу технологическому, через что такие вещи реализовывают, как правило?

[xokc]

Любая JSON based NoSQL DB решит все ваши проблемы. Типа mongodb, REDIS, djon, RIAK и т.п. - их сотни. При желании можно найти и аналоги для XML based DB, но XML сейчас не в моде. Сериализуете свои объекты в XML/JSON и отдаете их в базу. Потом читаете прямо из базы именно те ветки, которые нужны - об индексировании и "правильной" выборке позаботится движок БД.

[Zerkin]

Любая JSON based NoSQL DB решит все ваши проблемы. Типа mongodb, REDIS, djon, RIAK и т.п. - их сотни. При желании можно найти и аналоги для XML based DB, но XML сейчас не в моде. Сериализуете свои объекты в XML/JSON и отдаете их в базу. Потом читаете прямо из базы именно те ветки, которые нужны - об индексировании и "правильной" выборке позаботится движок БД.

А мне казалось, что XML вполне популярен  

Ну, не важно, допустим XML или JSON, т.е. по сути Вы предлагаете  следующее решение - N-xml/json файлов?

[Bepec]

Бд он предлагает.

[Zerkin]

Это я понимаю, но физически это всё-таки множество xml файлов будет? Просто ими будет управлять встроенная БД, так?

[xokc]

Физически - это ОДИН (может два, в зависимости от конкретной БД) файл с данными и API для доступа к нему в (возможно, в виде dll - опять же в зависимости от типа БД). Никаких XML файлов. XML - это просто способ обмена информацией между программой и БД.

[Zerkin]

Физически - это ОДИН (может два, в зависимости от конкретной БД) файл с данными и API для доступа к нему в (возможно, в виде dll - опять же в зависимости от типа БД). Никаких XML файлов. XML - это просто способ обмена информацией между программой и БД.

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

Хорошо бы действительно иметь это в виде библиотеки, и через интерфейс взаимодействовать. Понимаю, что вариантов много, но не могли бы Вы подсказать какие-то "лучшие практики"? Что выбрать?
Сама среда, все инструменты и модули полностью написаны на Qt, соответственно, если внедрять сюда работу с такой БД, нужно свести к минимуму все вопросы совместимости.

[xokc]

Какая ОС?
Навскидку UnQLite, EJDB, вроде mongodb встроить можно.
Вообще, наберите в гугле что-нибудь типа Embedded C++ NoSQL Document Oriented Storage.

[Ильин Евгений]

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

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

XML, JSON, бинарные данные или другие форматы, зависит от необходимости человекочитаемости настроек и изменения их вручную.

[Igors]

На Mac использую стандартные Preferences, на Вындоуз приложение создает папку Preferences рядом с exe. Плагинам путь сообщается, они могут писать туда свои файлы. Реестр - нет, по изложенным выше причинам. Формат сохранения - любой "теговый"

[Zerkin]

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

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

XML, JSON, бинарные данные или другие форматы, зависит от необходимости человекочитаемости настроек и изменения их вручную.

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

[Zerkin]

Какая ОС?
Навскидку UnQLite, EJDB, вроде mongodb встроить можно.
Вообще, наберите в гугле что-нибудь типа Embedded C++ NoSQL Document Oriented Storage.

Разработка конкретно под винду, повторюсь