>-----Original Message----- >From: mugisha moses [mailto:mossp...@gmail.com] >Sent: Thursday, May 28, 2009 12:11 AM >To: Arthur Fuller >Cc: mysql >Subject: Re: Can a MyISAM DB hold /everything/? > >what if you had no issues of scaling, which would have less access >time, file system or database? > [JS] I don't know that there is a definitive answer, but I would also lean in the direction of storing a pointer rather than the image itself.
= Either way, you have to retrieve the relevant row from the database so you incur that overhead. + If you store the image as a blob, retrieving the row should cache the blob in MySQL's buffers. - Since images are going to be both big and of vastly different sizes, if you put them in the table rows it probably makes MySQL work harder to manage space in its own files. - Since MySQL doesn't use raw partitions, retrieving the row goes through the file system anyways. + Using a flat file for the image also goes through the file system, but I suspect that most file systems are better at reading flat sequential files than they are at reading the random-access files of which a database is composed. (It's been a long time since I worked with *nix file system internals.) >On Thu, May 28, 2009 at 1:54 AM, Arthur Fuller <fuller.art...@gmail.com> >wrote: >> I second that emotion (don't store the images in the data file: just >store >> the paths to said images). Why? Because in the event of an updated >image it >> is more hassle than it is worth, to drop the old image and replace it >with >> the new one; if what you store is a simple pointer to an image file, >lots of >> this work goes away. >> >> A. >> > > > >-- >skype name : mossplix >twitter: @mugisha > >-- >MySQL General Mailing List >For list archives: http://lists.mysql.com/mysql >To unsubscribe: http://lists.mysql.com/mysql?unsub=jschwa...@the- >infoshop.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
