On Sat, 2004-10-30 at 22:30 +0000, Matthew Weier O'Phinney wrote: > * Robby Russell <robby@xxxxxxxxxxxxxxx>: > > On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote: > > > App needs to allow users to upload pictures. (jpg and gif), > > > needs to create thumbnails of those pictures > > > and to store thumbnails and full pictures. > > > > > > App needs to manage all those files - can be as much as 20K plus > > > images. > > > > > > I think image file size, file type and image dimensions restrictions > > > should be easy to handle by using $_FILES array and getimagesize > > > function. > > > > > > The issues that I am thinking of and need suggestions about are > > > > > > 1) Storage and retrieval - File system sounds like a better choice > > > over database. We are talking about 20 thousand plus pictures. > > > > I would do it in the database (PostgreSQL in my case). The speed isn't > > going to be much slower if you keep things optimized. You can even cache > > your images if necessary on the filesystem (for high traffic images). > > I have difficulty believing retrieving an image from a database will > have similar speed performance as simply grabbing it from the > filesystem... and if you're seeing a need to cache images on the > filesystem anyways, that's certainly already an argument against it. > I tend to stick as much in the database with strict restraints. I know that in my database, an image cannot be deleted unless several rules are met. In the filesystem, a number of things could accidently delete the wrong file. I treat my images as another piece of data and that data is kept there by constraints. > > > 2) Thumbnails - Should I create those once and save it in a file when > > > the image is uploaded for the first time. Looks like a faster option > > > than creating them every time on the fly. > > > > I just recently finished working on a project where I knew that would > > automatically create a thumbnail version of each image on upload... but > > then I realized that I might one day want to change the default > > thumbnail sizes.. so what I did was have it create a thumbnail on the > > fly from the database. (this way I can control the thumbnail size in the > > future). The speed difference was hardly noticed. I have done what I > > mentioned above and am now caching images that get loaded frequently. > > Thumbnailing on the fly may have decent performance, but it *is* slower > than simply serving up an image. If you doubt that, try surfing from a > T1 connection some time (dial-up users may not notice the extra time > required to generate the image, but those on broadband will). In > addition, if you generate a thumbnail every time the image is requested, > you're making your server do extra work -- even if you're caching > oft-requested images. > > I understand the argument regarding a future change in thumbnail sizes. > However, generating thumbnails on a filesystem of images is something > that is easily scripted and can be performed on an as-needed basis. > (ImageMagick is great for this sort of thing, and scripts in PHP using > GD could also be used.) > As I can do when I want it to be a thumbnail. Infact, in PostgreSQL, I can use plPHP, plPerl, psycopg, etc and perform these tasks within database functions. This isn't an issue at all. Here are a few reasons why storing in the DB can be more useful. http://www.oracle.com/technology/products/intermedia/htdocs/why_images_in_database.html Also, Gallery 2, is moving to a database backend, one would wonder why that would be a good move, considering the sole purpose of gallery is to display images. -Robby -- /*************************************** * Robby Russell | Owner.Developer.Geek * PLANET ARGON | www.planetargon.com * Portland, OR | robby@xxxxxxxxxxxxxxx * 503.351.4730 | blog.planetargon.com * PHP/PostgreSQL Hosting & Development * --- Now supporting PHP5 --- ****************************************/
Attachment:
signature.asc
Description: This is a digitally signed message part
