On Wed, 2007-02-28 at 22:08 -0500, markw@xxxxxxxxxxxxxx wrote: > > On Wed, 2007-02-28 at 17:04 -0500, Mark wrote: > >> Kevin Waterson wrote: > >> > >> > This one time, at band camp, zerof <zerof@xxxxxxxxxxxx> wrote: > >> > > >> >> It is not a good practice to store pictures in DataBases, use links, > >> >> instead of. > >> > > >> > Rubbish, where are your benchmarks? > >> > >> It has almost nothing to do with benchmarks. > >> > >> Images are typically best supported in the form of files. They are more > >> easily manipulated by external tools. > >> > >> The web browser sees an image as a single HTTP request. Invoking the PHP > >> script engine, parsing the script, and executing a SQL query to retrieve > >> the image from the database is less efficient than letting the web > >> server > >> just send the file. > >> > >> Image files do not need to be constrained by the rigid requirements of a > >> relational database. > >> > >> I could go on, but it should be clear enough that putting images in a > >> database is not a good idea. > > > > What about when you need to share those files across a 50 node network? > > Without more information about the nodes and the network design, I can't > offer a good argument against it, Oh, let's just say 50 nodes across the internet -- no specific location. And remember, I don't want to have every file on every server, I may have petabytes of data. Feel free to comment. > but I can say, that given any rational > system, bitmap images are better as discrete files than contents of a > database. I'd argue that's only true if you need to modify the contents, and you can't do so without a copy on the filesystem. Otherwise I'd have to disagree. Databases implement their own filesystem for the most parts. In fact many newer bleeding edge filesystems are practically database implementations. As such, the OS and the Database are merely layers over the raw medium. Sure the database is often layered over the OS's implementation of the filesystem, but that is not necessaril true since some databases support raw access in which case they're performance is probably just as good as the OS (and quite probably better if you want to store meta information about the file and it's data). > If you give me more information, I can counter with more specifics. I don't have specifics, I was just giving a sample scenario from the top of my head. > > I'd keep it in a database, then when I need it cache a local copy on the > > filesystem. Then I can just check the timestamp in the database to see > > if the file has changed. Voila, multi-node high availability images. > > You can do that sort of operation with any number of other tools more > efficiently. Maybe... and even so, are they just as convenient? Why implement multiple protocols when one will suffice? KISS! > > Seems better than have a local copy of every single image. I guess the > > answer is... it depends on what you're doing! > > No, it just seems like if the only tool you are comfortable with is a > hammer, then every job is more or less exactly like a nail. I'm quite comfortable with many tools. But if it looks like a duck, and walks like a duck, then I'm sure the hammer will suffice. > Databases are great tools, but there are many tasks which they can do, > just not well. Well one thing I know the webserver itself and the filesystem can't do is check the credentials of a logged in user to see if they are allowed the file. Well, I guess the webserver could do it... sort of... with http auth. Wonder if that works with many custom authentication systems... I presume you would somehow cram that into the webserver? I guess if the only tool with which you're comfortable is a screwdriver, then every job is more or less exactly like a screw. As such, I think you're screwed. Remember, I said it depends on what you're doing, you said "no", and well quite frankly you're wrong, because your screw and screwdriver mentality doesn't work in every imaginable scenario. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
