Quote:
Originally Posted by guma
There are multiple entries for each epub (one entry per html split) with a lot of properties/flags in this database - and this in two tables: tbl_content and tbl_volume_shortcovers). That could explain the DB size increase per book. Maybe this also explains the slow updating/DB-building speed: unpacking the epub files in bulk might well take some time. (But this is just speculation since I have no idea what to expect from a Linux based device with the processing power of an ebook reader in terms of file handling).
|
For an epub, it is one entry in the content per TOC entry plus the main row. Then the volume_shortcovers has a matching row for each of the TOC entries. For kepubs, there is an entry per TOC plus an entry for each HTML file in the manifest.
They do need to unpack the files, but they should only need to read the OPF and NCX files to get this information. The don't validate the TOC against the HTML files. I have tested this by putting an epub on the device were the TOC was nothing like the files.
Quote:
|
Anyway: the database, while not elegantly designed, is still small by any standard and should be easily manageable by the device - assuming reasonable programming that is ...
|
The database also grows because of they way they use it. They don't generally update rows in the database, they do a delete and insert. Depending on the cleanup of SQLite, that can leave a lot of unused space.