> 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.
OK, sure.
First, are you saying that 50 nodes, spread across the internet, all have
access to your SQL database? Yikes.
>
>> 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.
A data storage system within a file system. It is a subtle difference.
> In fact many newer bleeding edge filesystems are practically database
> implementations.
Not even bleeding edge. Think of the UNIX file systems, many use file
names merely as indexes to inodes which point to files. Very
database-esque.
> As such, the OS and the Database are merely layers over
> the raw medium.
To a point, this is true, but layers with different purposes.
> 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
Absolutly, raw access can speed up SQL databases with, of course, certain
caveats.
> 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).
Well, here's where your probably wrong. Depending on the database, of
course, as PostgreSQL, MySQL, Oracle, DB2, etc. all have different
behavior characteristics.
Now, first the only point in your argument thus far has been performance.
There are more issues involved, but for the moment lets argue that simple
point.
A file system is designed to take a file name, find its location on disk
or in cache, and return it. (Obviously simplified, but you get the point)
A database is designed to accept a query, parse the query and produce a
good access plan for the data requested, and return the data.
In many databases, blobs or binary objects are merely stored as files
outside the data tables. Even if they are stored in your database they are
large and possibly compressed. Either way they are large.
If the bitmaps are stored as external files, then performance wise, you
have the overhead of the SQL query in top of your file access.
If the bitmaps are stored in the database, then they take up cached blocks
that the database manage and reduce overall performance of the database.
>
>> 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!
Scalability and reliability and performance all come from keeping
logically separate functions being done separately.
>
>> > 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.
It only looks like a duck if you ignore the horns, hooves, and teeth.
>
>> 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.
This is true.
> 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.
In the case of a bitmap file that needs auth, I would use the session and
a PHP pass through code and avoid the database.
if($_SESSION['bitmapok'] == 'yes')
{
$bitmap = fopen($bitmap_file_name);
......
}
I'm not sure of your design, but typically speaking, the database back-end
is the bottleneck, and web services should limit access if possible to
improve performance.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
