Scott Haneda wrote: > 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? > Could you clarify/expand on this a bit - I am setting up a site where I expect to have a lot of images, both still and flvs, and a lot of recipes (including ingredients, procedures ad text :& ;images). I am storing the images in /images directory. If the amount of images gets rather large, you are suggesting to store them on another server, right? Now, with a lot of recipes, I understand that I should be storing them also on another server; and perhaps using XML to store the recipes. Does that sound like I have understood your advice? TIA
-- Hervé Kempf: "Pour sauver la planète, sortez du capitalisme." ------------------------------------------------------------- Phil Jourdan --- p...@ptahhotep.com http://www.ptahhotep.com http://www.chiccantine.com/andypantry.php -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
