Каталог электронной библиотеки
Nov. 27th, 2009 12:59 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerВ связи с тем, что lib.rus.ec окончательно скурвился я купил себе 32Гб SD-шку, возникает вопрос о работе с НУ ОЧЕНЬ большим набором электроных книг.
И да, primary target platform - maemo.
Т.е. возникает задача хранения каталога библиотеки отдельно от самой библиотеки, периодической актуализации и т.д.
Основная операция с этим каталогом - найти некоторое множество книг и вытащить его в "рабочий набор", то есть в случае maemo в рабочий каталог FBReader-а, владельцы всяких lbook-ов и openinkpot-ов лучше знают, что у них там.
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
phd тут рекламировал MyRuLib. Мне не понравилось. Во-первых, оно требует свежего wxWidgets. Более свежего чем в lenny (хотя пакет якобы для Debian 5.0 на сайте есть), так что даже на десктопе попробовать не получилось.
Во-вторых, в maemo вообще с wxWidgets туго.
В третьих, залез я в их базу данных посредством sqlite и показалось мне что проектировал её типичный php-кодер. Поле genres в таблице books, содержащее конкатенацию каких-то кодов...
Вот и думаю теперь что делать. Либо пытаться все же использовать эту заботливо подготовленную неграмотными людьми базу, либо писать свою извлекалку метаинформации из fb2 (pdf и djvu меня интересуют меньше, потому что на 32Гб флэшку они не влезут и читать их на экране 800x480 неудобно).
Либо вообще прикрутить sqlite-каталог к FBReader-у.
Но вот как должен выглядеть интерфейс этого библиотечного приложения?
Очевидно что просмотр списка из десятков тысяч авторов - не вариант. Тем более что нужен поиск по сериалам (sequence) или названиям.
Столь же очевидно, что о полнотекстовом поиске сразу надо забыть. Сделать полнотекстовый индекс существенно меньший по объему, чем сама библиотека вряд ли удастся, а библиотека занимает более половины доступного объема.
Ничего лучшего, чем повторить форму поиска на сайте lib.rus.ec мне в голову пока не приходит
И да, primary target platform - maemo.
Т.е. возникает задача хранения каталога библиотеки отдельно от самой библиотеки, периодической актуализации и т.д.
Основная операция с этим каталогом - найти некоторое множество книг и вытащить его в "рабочий набор", то есть в случае maemo в рабочий каталог FBReader-а, владельцы всяких lbook-ов и openinkpot-ов лучше знают, что у них там.
phd тут рекламировал MyRuLib. Мне не понравилось. Во-первых, оно требует свежего wxWidgets. Более свежего чем в lenny (хотя пакет якобы для Debian 5.0 на сайте есть), так что даже на десктопе попробовать не получилось.Во-вторых, в maemo вообще с wxWidgets туго.
В третьих, залез я в их базу данных посредством sqlite и показалось мне что проектировал её типичный php-кодер. Поле genres в таблице books, содержащее конкатенацию каких-то кодов...
Вот и думаю теперь что делать. Либо пытаться все же использовать эту заботливо подготовленную неграмотными людьми базу, либо писать свою извлекалку метаинформации из fb2 (pdf и djvu меня интересуют меньше, потому что на 32Гб флэшку они не влезут и читать их на экране 800x480 неудобно).
Либо вообще прикрутить sqlite-каталог к FBReader-у.
Но вот как должен выглядеть интерфейс этого библиотечного приложения?
Очевидно что просмотр списка из десятков тысяч авторов - не вариант. Тем более что нужен поиск по сериалам (sequence) или названиям.
Столь же очевидно, что о полнотекстовом поиске сразу надо забыть. Сделать полнотекстовый индекс существенно меньший по объему, чем сама библиотека вряд ли удастся, а библиотека занимает более половины доступного объема.
Ничего лучшего, чем повторить форму поиска на сайте lib.rus.ec мне в голову пока не приходит
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-11-28 04:18 pm (UTC)Файлы не копируются, а делаются жёсткие ссылки, поэтому места дерево почти не занимает. Если у текста несколько авторов, то создаётся каталог и мягкие ссылки с каталогов отдельных авторов. Дерево на 7,5 тыс. файлов строится секунд за 13 (не считая сканирования ФС).
Теперь вот думаю, что следует разделить задачу. Отдельно сбор метаинформации (простая база: имя файла — метаинформация) и отдельно построение дерева. Тогда построение ещё быстрее будет. Да и простые запросы делать можно будет.