> 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 :-) With regards, Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
