Please, by all means, feel free to make this argument to my boss...
Zed A. Shaw wrote: > On Sat, 01 Sep 2007 13:46:18 -0400 > Will Green <[EMAIL PROTECTED]> wrote: > >> Not necessarily so, Ezra. Storing images in the database is perfectly >> legitimate. However, just like Rails HTML views, you could implement >> caching of the images on the filesystem (i.e. write them to both the FS >> and the DB). Whatever action "renders" the image could take care of >> caching on the FS, serving the FS version if the DB version has, for >> example, the same MD5 hash as the one in the DB. > > No, not right at all. All RDBMS were originally designed to store relations, > not files. It's only recently that people started putting every damn thing > they could into a RDBMS. The smart folks just put the data on a file system > behind a specialized image web server. Then, when you need to serve the > image, you, uh serve it. Doesn't get much easier than that. > >> Yes, performance will be a bit less than pure FS, but backups are a >> whole lot simpler (just backup and restore the DB). Besides, servers are >> cheap compared to developers (just ask the 37s guys), right? > > That's it? Backups? Seriously man, that's a lame reason to do anything. > Especially since backing up a file system is *infinitely* easier than a > database. In real companies around the world there are little children > crying because every night the DBA has to shut the production databases down > to back them up, even if Oracle says they don't. > > Backing up a file system does not require shutting it down, and can even be > done with just simple rsync scripts. > -- == Will Green Find out why this email is 5 sentences or less at http://five.sentec.es/ _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
