Re: Q & A (Images in a database)

Wrench in the works... Storing images in a file structure are quick from the onset, however file management quickly becomes an issue. When file count in a single directory contains more than 1000 files there is a serious performance hit. Most if not all operating systems file structures have this difficulty. There are a couple of solutions. 1. One solution is to store images in an elaborate directory structure, which is designed to keep file count in any given directory <= 100. One of the easiest ways to manage is a structure where all images are stored with a filename as a number and the full path to the image is also the number. /images/00/00/00/00000000.jpg /images/01/99/99/01999999.jpg /images/12/34/56/12345678.jpg With a scheme like this, you're limited to 100 million file names. But seek time is fairly quick. 2. Store images in a database. This can be more trouble than it sounds. An interface that stores images in the database is required, as well as one to retrieve the images from the database. Aside from the interface storage retrieval, you next need to be concerned with tuning the database so that slack isn't a deciding factor issue, or you will eat up more database space. I'm familiar with Oracle. It has a nifty rule set to facilitate the expedition of table updates. Look up percent_free when creating tables and/or tablespaces. -- I was pro database storage until I started writing this message. Now I need to weigh the pros and cons again. ;-) -Joe ""Cosenza, Mario"" <mcosenza@engsvcs.com> wrote in message news:A8F517777541D411BFFB02204840172112BDC9@EXCHANGE1... > This seems to pop up a lot on this list. > > I don't know if there is a perfect answer, it tends to be more of personal > preference. > > Storing the image in the database causes, a very large database, and a > separate call to load the image. > > The final output of the HTML code has to execute a php script to get the > image. Like this (HTML code) <image src="getimage.php?id=27">. > > First you generate the page (index.php) when it's loaded, then when the page > is processed (by the client) they have to make another call to get the image > (with getimage.php). The client has to call getimage.php each time it needs > an image. > > Because of this I've leaned towards storing the path to the image in the > database (and put the images in a directory on the server). This keeps the > image table small (and hopefully faster). > > And the HTML code that is processed on the client doesn't make a second PHP > call to get the image (It still has to go back to the server to get the > image file, but it doesn't have to execute PHP code and pull it out of the > SQL databse. > > In conclusion, I beleive (but hey, who the hell am I anyway) that it's > simpler, faster, and takes less resources to call images from a directory in > the server. You're not overworking PHP, or SQL, just the HTTP server. I > don't know anything about the actual impact on system load, it just seems to > make sense to me (for some reason). > > Hope this helps. > > Mario > > > -----Original Message----- > From: Bart A. Verbeek [mailto:b.a.verbeek@wanadoo.nl] > Sent: Monday, October 09, 2000 10:16 AM > To: php-db@lists.php.net > Subject: [PHP-DB] Q & A > > > Hello, > > Hope all you people can help me again.... > > I want to create a database with pictures (and descriptions). Is it better > to store the picture in the DB itself or is it better to store the pictures > in a folder (say 'pictures') and store the path (to picture) in the DB with > the description. > > Wich one is faster? In DB-stored pictures or php/MySQL-generated file-paths > converted to HTML?? > > Hope you all have an answer? > Regards > > Bart > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net > For additional commands, e-mail: php-db-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >