> Since I want the ability to mirror, it seems that I'll probably want one
> single DB replicated across my hosts so that comments and so on stay up
> to date (I still haven't crossed the bridge of how to keep the library
> itself in sync thru something like unison or rsync, but I do know that I
> really don't want to keep the files in the DB itself). I'm open to ideas
> of why I wouldn't, though.
Well, putting the files themselves in the database would solve
your replication problem :-)
All in one, one in all...
> My real question comes down to table layout. Given the customer data as
> above (in much more detail, of course), I'm not sure whether I want a
> table structure for each customer (presumably instantiated as part of the
> site setup, but perhaps created by the code in a "check this first before
> you do anything" section) or a single large table structure.
IMO, a single table structure. Unless you want to give each customers
its own _database_ (not just tables in the same database).
> The latter
> seems more straightforward to me, and since it's a DB it shouldn't matter
> if the 'pictures' table (or the like) gets to be a million rows, but what
> I don't know about DB design would fill a book :-)
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL