On Tue, July 11, 2006 11:38 am, Eric Butera wrote: > I don't see a problem with storing images in the DB IF they aren't > going to be continually accessed that way. For example say you have a > script that lets a user upload an image and creates a small, medium, > and large view out of it. Stick the original in the Db and then make > your 3 sizes on the fly and cache the output so they are not > continually created. This way you could down the road re-do all the > sizes if you go through a site redesign or the client chooses they > want them 450 instead of 400. =) And this would be better than just throwing the original in the file system in what way?... I'm sure not seeing a "plus" to having the original images in the DB instead of the file system here. I *just* do not understand why you'd want to cram this ginormous chunk of binary data into the DB. You're NOT going to sort on it. You're NOT going to filter it based on what's in the binary data. There are ZERO functions internal to SQL that can do anything at all useful with the data. Maybe if MySQL had GD integrated, and you could do: SELECT imagescaled(image, 400, 300) FROM images But it doesn't. And you're not the CIA using AI feature recognition to compare the photos in your DB with an SQL function. You're just shuffling data through layer after layer after layer of DB calls so it can sit on the same damned hard drive, clogging up the DB space, and making HD disaster recovery of the data in the DB far far far more difficult. And for what? To avoid a few lines of code in your web application to keep the db and file-system in sync? Puhlease. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
