Hi folks... I'm also new to CPG.
Since this is a general discussion forum, may I present some reasons for storing pics in the RDBMS? It's something I'm heavily in favor of and I was kind of dismayed to find CPG didn't have this feature after having already committed to it. Not surprising though.. it seems most open source PHP+MySQL apps end up being this way.
Where I'm coming from: I just recently started using CPG for myself just a couple days ago... loaded about 6000+ images into it. Aside from that though, I admin a server (co-located, but we own the machine) that provides stuff to a dozen or so friends / small organizations: shell accounts, web hosting, installs of things like wordpress, coppermine, phpbb, vbulletin, etc. There's probably 6-10 coppermine installations on this server right now. I also happen to have both the web server and the DB server on the same physical machine, but there are many situations (if we were a larger operation) where this would not be true. As for all that stuff earlier in this thread about finding good webhosts and stuff--it doesn't really apply to me... though I'm guessing that a majority of coppermine users do that and have those concerns.. I do not.
The primary reason one would want to store pics in the DB is for backups. CPG has no built-in backup mechanism.
On the MySQL side, that's not a problem, backing up every single mysql database on the server (all the coppermine installations plus other apps) is incredibly easy and elegant to do as an admin with a few well-written perl scripts. The nice thing is that you can set up a good backup schema of "occasional full dumps" + "daily incremental dumps" by using the mysql binary update log (or if you want to be hard core, you can use the replication features). This reduces the amount of bandwidth we'd have to use because, honestly, doing a full network dump of our system takes forever. Anyway, because we (and pretty much anyone else in a similar situation to us) already have a mysql backup thing going, backing up the mysql-end of Coppermine (all of them) is effortless. It really does kind of make you wish that everything could just live in the DB.
There are two other components to coppermine and both are stored in the same area of the file system: the photo data (original images plus thumbs + intermediates) and the CPG code. Of course, the code must live in files and on the web server. That's always a given. In my case, the code is easy to back up because we put them into a version control system (plus any themes/mods/hacks they've applied). The photo data could either live in files on the webserver, or it could live in tables on the db server. Currently, I dont' have a way of easily backing up the albums directory for the half-dozen (and more to come) installations...
One thing I'd like to point out in the area of backup though: it is not necessary for all the files in albums to be backed up--just the original images (because, in theory, the thumbs / intermediates can be restored from the originals + some other config settings that are stored in mysql).
The secondary reason comes down to server design / appropriation considerations. In larger setups (or even small ones if you're thinking on a corporate level), you will often purchase a separate web server and database server. The web server will often be a fast and lean machine, 1U, not a lot of disk space--I mean, all it has to hold is OS + web server + app code. The db server will often be a large machine with lotsa disk, backed up often, perhaps RAIDed, etc. If the web server blows up, dropping in a spare is almost trivial and probably wouldn't even involve much of a "restore" process. But if the web app is relying on the local file system to store some very large files, then your web server starts needing a lot of storage space--either that or you have to do some undesireable thing like NFS-mount a disk partition and symlink everyone's "albums" dir over to it. In any case, it becomes a pain, and suddenly your web server has to be much more than it originally was and it's questionable whether separating the two machines held any advantage anymore.
Again, for the secondary issue, I'll point out that, since the thumbs + intermediates are orders of magnitude smaller in file size than the originals, it really only matters that the originals get put on the DB.
The primary concern that I wish to contest is typically that putting large items in the RDBMS will slow the database down. I can't agree with that... why would that be true? It would be like saying that putting large files in the file system would slow down your access to any other file on the same partition. Databases aren't that dumb.. the whole point is that they index things well, and when it comes to storing big things like this, it's pretty much the same as putting it on the FS except for the fact that you can't seek to random points in the file (you have to slurp the whole thing down at once if it's in the DB)--but that isn't an issue for things that are just going to be served over the web. It is an issue for programs that have to read over a file and jump to different parts of it and read it again.
The secondary concern that I will partially agree / disagree with is that moving these items to the RDBMS will slow the overall operation of Coppermine down. Yes and no... for example, if you want to access an image that lives in the DB, then yes, Coppermine (PHP) must pull it out of the DB (and do all that communication w/mysql) before sending it out--instead of pulling it out of the FS (and doing all that communication w/the kernel FS code) before sending it out.... it may be a tad slower, especially if the DB server is a physically distinct machine from the web server. This is true. However, if all you're storing in there are the originals and not the thumbs/intermediates, this becomes barely true at all--it only becomes a concern when people click on the thing to see a large image.
Another concern I alluded to earlier is that you can't easily run arbitrary programs (ie, ImageMagik) on something that's not a file. Sometimes you can run them on pipes, but not always... anyway, the point is that if you had to do any re-generation of thumbnails/intermediates after your original file got sucked up into the RDBMS mothership by the batch add scripts, the CPG code would probably need to slurp down the image from the DB, write it to a file, run the program, read it back, etc, etc. I mean, in general, making CPG work in this way seems like you'd have to change a decent number of PHP files...
Well, thus ends my argument for storing pics in the DB. While it's important enough to me that I'd normally go try to hack this myself... I'm busy enough as it is hacking other software packages. Let me know what you think though.