[Digikam-users] Some questions about digikam4.db

[Jean-François Rabasse]

On Thu, 10 Nov 2011, Anders Stedtlund wrote:

> Hi Jean-François,
>
> digiKam used to have thumbnail images in the file system. Do you
> suggest that the thumbnails db should be removed in the future? (If I
> read between the lines...)

Hi Anders,

Oh no, I didn't meant "removed"; having thumbnaisl under hand is an
important feature for such an application.
My opinion is that that kind of data, thumbnails or fingerprints,
should probably not be part of the master DB file.
Because it's not part of the DB schema, it's only auxiliary data,
setup in advance for faster access upon need, and can be rebuilt at
any time, so don't need to be backuped even in case of disk disaster.

But saving that data "outside" the master DB, be it into another DB
file or in the file system, or whatever, is of little importance, the
application knows how to get it and it's only a development choice.

The inconvenient of "packing" all in one DB file is size (as was the
start point of this thread). When one looks at Digikam versions using
two files, digikam4.db and thumbnails-digikam.db, one sees the second
file is about 10 times bigger !

Jean-François

PS: another argument for the "splitted" philosophy is when an images
application runs on different machines. It's probably not a Digikam
issue, but it's a common configuration in web based images bank 
applications; the main application (CGI program) is on one machine
running a HTTP server, the database is on another machine running a
SQL server, Oracle, PorsgreSQL, MySQL, etc., protected on a local
network.
The design rule says "data should be where it's needed", so the
application will access master DB data via SQL requests, but will
load and send/display thumbnails images from it's local disk system.
If you put thumbnails in the main DB, you jam your local network
bandwidth.

So, splitting -> more flexibility and in some cases higher performances.