With regards to Marek, I don't see how there would be two queries, because there row conisists of image properties and image data. So when i select the required row(s), I will have properties and images. So it will be 1 query, of course it is a big (size-wise) query.
With regards to Jason, Your approach is reasonable. I guess I will have to judge for myself! "Bobby Patel" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hello, > I have the Images table setup with columns (width, height, size, type, > etc...) the question is should I have the image data stored in this table or > disk? > > I know, alot of people have said it is faster in disk, which is 1 page I/O. > But I need these images for displaying product pages, and I believe that it > would be faster to just pluck the properties from the dB (including the > image file) . > > Usually I will need to pull 6 or 10 images per page, this is my rational for > this situation: > > If all stored on db: > One query - will take about 4-5 page I/O (assumiing index on filename) > > If just properties stored on dB and image on disk: > One query to grab the rows of properties - 2-3 page I/O > to grab 6 or 10 images - 6 or 10 page I/O > Total - 8 - 13 Page I/O's > > If all images stored on disk, no dB whatso ever: > to grab 6 or 10 images - 6 or 10 page I/O > cpu time to run getimagesize() for each image - CPU time unknown? > > I assume that "page I/O" is that same as "disk access". > > I AGREE that storing images strored on disk is a valid approach PROVIDED > that you only need 1 image per page, but if you need to grab a bunch at a > time, I do beleieve that storing the actual file on the dB is faster. > > I would like to hear from the list, of people that have worked with images > and PHP. I just started with images, so I just want to take the right path. > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
