Unless you have very good reason to store binary data like an image in
your database, do not. It may work well for a time, but always be
prepared that your system will grow. If it grows a good deal relative
to your hardware, and users, and connections etc, you will always be
in a race to "throw more hardware" at the problem.
In a simplistic terms, an image is a file, files should be stored on a
file system.
You can do some very nice and simple things later on to distribute
image loads. If you store the path to the image, so example, "images/
date/time.jpg", and then need to grow your serving needs, you could
adjust your code in the http request to call images.example.com as the
hostname. You could set images.example.com to return round robin DNS
records.
Now all you have to do is mirror or sync your images directory to any
number of high performance http servers.
That is just one example of how I have avoided dealing with binary
file load in MySql, or any database for that matter. Even a reltively
small image stored in a database can become a lot of data very fast.
You will also find it can be inefficient to fetch that data and show
it to the end user. At the very least, you have to request the data,
read it, rebuild it into a form that can be displayed to a user, which
is a lot of work, compared to no work at all if just calling it from
the file system.
Your question about which is faster, always will be on disk binary
storage, with the exception of deletes. Deletes will happen in near
the same time, though you do have to locate the record to delete.
This probably still has no impact, since you will locate on an index.
Hope that was helpful.
On May 27, 2009, at 9:50 AM, Pete Wilson wrote:
I am new to MySQL and just laying out what I hope will be just one
db that holds all the info for a list of forged or machined metal
parts.
Let's say there are 10,000 such parts, each with a unique part
number. That part number is the primary index.
Each part has at least one, and maybe several, accompanying photos.
And each part has at least one, and perhaps as many as five, human-
language descriptions. These descriptions might be as long as 5,000
characters each.
I believe I have the choice of:
1. Storing everything -- photos and descriptions included -- in the
database; or
2. Holding some info in the database; and storing photos and
descriptions in normal-type disk files apart from the database, with
names based on part numbers.
So my questions:
1. Which scheme is faster and less resource-hogging in reading,
updating, adding, and deleting?
2. I understand there are problems in storing photos in the db. Can
one overcome these problems somehow?
--
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
