GMane said:
For my database, I have a table of user information with a unique
identifier, and then I save to the filesystem my bitmap files, placing the
unique identifier, date and time information into the filename. Why stick a
photo into a database?
There are various possible reasons, depending on one's specific situation.
A database allows you to store the date and time info, or other
attributes, as separate fields so you can use standard SQL (or whatever
your favourite DB supports) to sort, query, and retrieve.
A database makes it possible to update or remove the photo in the same
manner you use to access all your other data, rather than requiring you
to deal with filesystem ideosyncracies and exceptional conditions.
A database such as SQLite will store *all* your data in a single file,
making it much easier to copy for archival purposes, to send to someone
else, or to move to another machine.
Then save the bitmap with filename:
0001_13:00:00_06-21-2005.bmp
A database shouldn't make you jump through hoops to create "interesting"
file names just to store your data.
To make things faster, I also have a table of filenames saved, so I can know
exactly which files I want to read in.
Oh yeah, databases can have indexes (or indices, if you will) which let
you get that sort of speedup without having to resort to still more
custom programming.
Not that a database is always the best way to store an image (or to do
anything else, for that matter), but there are definitely times when it
can be a better approach than simple files. (There are disadvantages
too, of course, such as making it harder to "get at" the data from
outside the application which created it. In the case of bitmaps, this
might well be a deciding factor, but each case should be addressed on
its own merits.)
-Peter
