At 21:58 2007-10-26, Mesdaq, Ali wrote:
I personally think that storing images in the DB is the best place to start because if other better solutions are available later you can very easily migrate. But if you start out with filesystem migration is a little bit more cludgy in my opinion. I mean you have to go traverse directories and copy/move/delete or whatever you have to do for the migration.
I haven't tried serving images or large objects from a database this way, but wouldn't reading this data totally blow the db cache for the rest of the things the database needs to do? At least it's something I'd investigate and create spike solutions for before deploying. It sounds very much vendor and/or configuration dependent, so off to the manuals :)
One thing that could work though, letting each component do what it's best at, is to let the db store and _manage_ the media assets, but to write them to disk on first access (and clear out unused files in a cache-like way) and let the web server _serve_ them efficiently.
/J _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
