>
> revised feature list....
Mostly looks very good, but ...
> Files in database
Assuming this means the actual image pixels will be stored in the
database, not in regular files & folders; this is, IMO, a bad idea.
Quite apart from the "all your eggs in one basket" principle, this
will increase the number of times each byte of data has to be touched.
(It will also make backups an expensive process, as adding even just
one new image may well necessitate saving the whole database again).
At a minimum, the image needs to be read from the disk, and the
server needs to stream the data bits over a socket to the browser.
If you pass the server an IMG tag, that's all that happens. But
if it's in a database then something other than the server has to
pull the bits out of the database and pass them to the server so
that it can hand them on to the browser.
Rather than trying to build everything into one single component,
I'd suggest using different pieces, each suited to their own task.
o Image files I'd store as regular files (in many folders);
the folder hierarchy would perform the most important
categorisations (probably image size at the topmost level).
o The database would contain all the metadata, EXIF data, etc.,
and the link back to the filename withing the hierarchy.
(I'd probably also store a flat text file in each folder with
database record ID and file name, just for paranoia's sake).
o I'd use CGI (probably just PHP or Perl) to generate the HTML
handed off to the server.
