выбор формата документа (для моей прграммы)

[nadge]

Давно уже у меня висит один проект: записная книжка с древовидной иерархией документов. Типа как файловая система с каталогами и текстовыми/rtf/etc файлами, только все в одном физическом файле. Сами документы могут содержать картинки и быть довольно большими. Но картинки вроде бы можно закодировать в base64 и хранить в теле html - пока думаю использовать этот вариант, если Qt это позволит.

Программу пишу на питоне. Прототип интерфейса я уже сделал на PyQT4, теперь вот пора делать "движок" для этой штуки. И вот тут возникает вопрос, в каком формате сохранять документ?

Предполагалось использовать SQLite с двумя таблицами: для структуры "каталогов" и для самих документов. Впринципе, это решение вроде бы должно устроить, но хотелось бы рассмотрть альтернативные варианты.

Может быть SQLite для "каталогов" и что-то из NoSQL для докуметов? Но все это в итоге должно сохраняться в одном файле.

А может вообще что-то другое?


З.Ы. Есть несколько моментов:
1. Предполагается возможность работы с приватными данными (которые у пользователя могут лежать в зашифрованном месте), поэтому не хотелось бы, к примеру, распаковывать zip архив в /tmp (если будут использоваться сразу два движка БД). Т.е. тут нужно какое-то разумное решение.
2. В одном файле теоретически могут быть тысячи документов, которые накопятся за несколько лет. Хотелось бы, чтобы это кушало не очень много оперативки.
3. Все что нужно для работы программы должно присутствовать в репах основных дистров (хотя бы в тестовых ветвях) или легко (без компиляции) туда ставиться.
4. Вообще круто: если сохраненный файл будет (при желании пользователя) зашифрован.

[kosmonaFFFt]

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

[eddy]

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

[Portnov]

libzip же, вроде, позволяет читать/писать zip-архивы, не распаковывая их? (см. pydoc zipfile, раз питон). Так что можно использовать формат, устроенный наподобие ODF (при желании можно согласовать некоторые детали и потом попытаться протащить свой формат как часть стандарта ODF ;)). А именно, zip-файл (можно с нулевым сжатием, для скорости), в котором структура документа описана в xml-файле, а сами тексты итп — вобще в любом формате, например в html. Картинки и прочее просто кладём в тот же zip-файл, можно в специальную поддиректорию.

[Denjs]

<...> Но картинки вроде бы можно закодировать в base64 и хранить в теле html - пока думаю использовать этот вариант, если Qt это позволит.
<...>

КюТэВебВью нормально так отображает стартовую страницу мини-яндекса - http://ya.ru/
там картинка как раз

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

<img src="data:image/png;base64,

.
Значит QT это позволяет)))))

[korisk]

fossil - хранит в одном файле - wiki, архивы и целый репозиторий с тегами и бранчами.
может пригодится..

[nadge]

КюТэВебВью нормально так отображает стартовую страницу мини-яндекса - http://ya.ru/

Значит QT это позволяет)))))

Отлично! Дисковое пространство дешевое (там же половина или треть размера где-то прибавится?), а такой вариант зато сильно упростит разработку. (Если конечно такие картинки без особых костылей добавляются в текстовый редактор Qt).

Так что можно использовать формат, устроенный наподобие ODF

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

а сами тексты итп — вобще в любом формате, например в html

С учетом того, что редактор на Qt, а там интегирован html, это представляется хорошим вариантом.

fossil - хранит в одном файле - wiki, архивы и целый репозиторий с тегами и бранчами.
может пригодится..

И хранит он это в SQLite? Впринципе, это был основной вариант, пока не предложили (подобие) ODF :)

Посмотрите в сторону XML для документов

Т.е. все документы в иерархии в одной структуре XML или для каждого отдельную?
Если второе, то как-то проще html, т.к. Qt в него экспортирует содержимое текстового редактора (xml вроде нету, да и разница не столь принципиальна будет).

Если же вообще все документы хранить в одном XML, то сама структура документов там может быть организована в виде дерева, а значит не нужно где-то еще хранить дерево. Вариант интересный. Можно именно так и расширить ODF - дешево и сердито, как говорится :)

Но не будет ли такой вариант тормозить? Там могут быть тысячи документов в иерархии.

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

Это каких например? Я просто не знаком с термином, а гугл сходу ничего не выдал.

[кып]

Может помогут в выборе формата всякие "карманные" wiki, например:
WoaS - Wiki on a Stick
TiddlyWiki

[Denjs]

В качестве формата хранения - да - можно использовать html со встроенными картинками. (увы не знаю как это будет поддерживать кт-шные виджет для редактирования текста)

Но вот в качестве хранилища я бы предложил вам использовать SQLite. Встраиваемая СУБД с "поумолчанию вкопиленной" поддержкой в Qt.
Ну и можно делать нормальные (ну или относительно нормальные) SQL-запросы по базе данных.

[frp]

Предполагалось использовать SQLite с двумя таблицами: для структуры "каталогов" и для самих документов. Впринципе, это решение вроде бы должно устроить, но хотелось бы рассмотрть альтернативные варианты.

Может быть SQLite для "каталогов" и что-то из NoSQL для докуметов? Но все это в итоге должно сохраняться в одном файле.

Возможные решения:
1. libzip или другой libформат_архивов
2. Если по дереву каталогов не осуществляются сложные операции поиска, то NoSQL можно и для каталогов применить - будет более эффективно.
3. (самое тупое, но наиболее простое решение (правда, не знаю, как сделать это без прав root)) Сделать этот файл обычной ФС и монтировать как loop.

[nadge]

2. Если по дереву каталогов не осуществляются сложные операции поиска, то NoSQL можно и для каталогов применить - будет более эффективно.

Сложные - это какие например? Вроде бы не осуществляются...

(самое тупое, но наиболее простое решение (правда, не знаю, как сделать это без прав root)) Сделать этот файл обычной ФС и монтировать как loop.

Есть вроде бы реализация ext2 через fuse. Можно попробовать с ней извратиться, возможно сделать к ней пару патчей... Но тогда уж проще SQLite или ODF использовать.

Но вот в качестве хранилища я бы предложил вам использовать SQLite. Встраиваемая СУБД с "поумолчанию вкопиленной" поддержкой в Qt.

Я ее ранее использовал напрямую (через одноименный питоновский модуль). Есть ли смысл в обсуждаемой программе использовать Qt-шную обертку над SQLite, а не задействовать эту БД напрямую? Просто я с Qt-шными интерфейсами к БД не работал.

Может помогут в выборе формата всякие "карманные" wiki, например:

Посмотрю. Перед ними впринципе похожая задача стояла...

[frp]

Сложные - это какие например? Вроде бы не осуществляются...

Если делается просто выбор файла по имени или получение списка файлов в каталоге, то с этими целями NoSQL должен справится лучше (хотя NoSQL бывают разные). Если делается поиск по регекспах, шаблонах и т.д. и т.п. (ну и другие вещи, где без SQL никак), то лучше-таки нормальная реляционная СУБД.

Есть ли смысл в обсуждаемой программе использовать Qt-шную обертку над SQLite, а не задействовать эту БД напрямую?

Это уже на ваш вкус. Хотя ИМХО Qt-шная обертка отстает (не все возможности СУБД позволяет задействовать, как и все универсальные обертки).

[nadge]

Если делается поиск по регекспах, шаблонах и т.д. и т.п. (ну и другие вещи, где без SQL никак), то лучше-таки нормальная реляционная СУБД.

Ну, вряд ли в такой программе нужен поиск в дереве по регекспам.

хотя NoSQL бывают разные

А какую посоветуете? Я пока ни одной не пользовался.

Это уже на ваш вкус. Хотя ИМХО Qt-шная обертка отстает (не все возможности СУБД позволяет задействовать, как и все универсальные обертки).

Т.е. она не даст заметных преимуществ (с учетом того, что вся программа на Qt)?

[frp]

Т.е. она не даст заметных преимуществ (с учетом того, что вся программа на Qt)?

Единственное - в Qt сразу есть модель для таблицы SQL и результата SQL-запроса. Но это вам вряд ли нужно, а если и нужно, то реализовывается за полчаса.

А какую посоветуете? Я пока ни одной не пользовался.

Если честно, я тоже.

[NickLion]

А ещё в Qt можно легко узнать № колонки по имени. А не высчитывать вручную, или изобретать какие-то костыли. В случае API sqlite, насколько я знаю, готовых таких вещей нет.