<p>Hi,</p>
<p>My fault. Didn't mean to remove the thumbnails, just the db and have the thumbnails in the filesystem instead.</p>
<p>The pro to have thumbnails in the same db as everything else must be that it's possible to join over that table in a single run. Now I assume that there's one query to find images and another query to find the thumbnails.</p>

<p>/Anders</p>
<div class="gmail_quote">Den 10 nov 2011 11:55 skrev "Jean-François Rabasse" <<a href="mailto:jean-francois.rabasse@wanadoo.fr">jean-francois.rabasse@wanadoo.fr</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Thu, 10 Nov 2011, Anders Stedtlund wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jean-François,<br>
<br>
digiKam used to have thumbnail images in the file system. Do you<br>
suggest that the thumbnails db should be removed in the future? (If I<br>
read between the lines...)<br>
</blockquote>
<br>
Hi Anders,<br>
<br>
Oh no, I didn't meant "removed"; having thumbnaisl under hand is an<br>
important feature for such an application.<br>
My opinion is that that kind of data, thumbnails or fingerprints,<br>
should probably not be part of the master DB file.<br>
Because it's not part of the DB schema, it's only auxiliary data,<br>
setup in advance for faster access upon need, and can be rebuilt at<br>
any time, so don't need to be backuped even in case of disk disaster.<br>
<br>
But saving that data "outside" the master DB, be it into another DB<br>
file or in the file system, or whatever, is of little importance, the<br>
application knows how to get it and it's only a development choice.<br>
<br>
The inconvenient of "packing" all in one DB file is size (as was the<br>
start point of this thread). When one looks at Digikam versions using<br>
two files, digikam4.db and thumbnails-digikam.db, one sees the second<br>
file is about 10 times bigger !<br>
<br>
Jean-François<br>
<br>
PS: another argument for the "splitted" philosophy is when an images<br>
application runs on different machines. It's probably not a Digikam<br>
issue, but it's a common configuration in web based images bank applications; the main application (CGI program) is on one machine<br>
running a HTTP server, the database is on another machine running a<br>
SQL server, Oracle, PorsgreSQL, MySQL, etc., protected on a local<br>
network.<br>
The design rule says "data should be where it's needed", so the<br>
application will access master DB data via SQL requests, but will<br>
load and send/display thumbnails images from it's local disk system.<br>
If you put thumbnails in the main DB, you jam your local network<br>
bandwidth.<br>
<br>
So, splitting -> more flexibility and in some cases higher performances.<br>
<br>
<br>_______________________________________________<br>
Digikam-users mailing list<br>
<a href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/digikam-users" target="_blank">https://mail.kde.org/mailman/listinfo/digikam-users</a><br>
<br></blockquote></div>