The times I have heard, "this is just a test, hack it together", or
"this will never see significant load" are more than I care to count.
Worse, the times that those statements ended up being false, and a
rigged and hacked demo code base become production has taught me to
treat all work as though it will become production.
That small rant aside...
Your question is hard to answer without knowing how you plan on
displaying the results of the data that comes out of the database. If
this is a case where you pull the data out and show it in a web
browser, then without question, less access time would be to store the
images in the file system. There is no access to if there is no
request for the image out of the database.
Even if you are not using a browser, I am having a hard time thinking
of many cases in which storing an image in the database is a good
idea. Then again, I am thinking jpg, png, gif etc. Could be by image
you mean a highly structured bitmap pattern, or pure vector
coordinates that render an image out to SVG.
I do have one question. If you can make the statement that scaling
will never be an issue, then you why does it matter? In a non
performance driven environment, you should pick the most convenient
method to manage, and not worry about performance or scaling, if you
have that luxury.
On May 27, 2009, at 9:10 PM, mugisha moses wrote:
what if you had no issues of scaling, which would have less access
time, file system or database?
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.
--
Scott * If you contact me off list replace talklists@ with scott@ *
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
