On Fri, 2007-03-02 at 11:01 -0500, markw@mohawksoft.com wrote:
I'm going to mostly skip your drivel... and cut straight to a short
comment and an example proving the invalidity of your general argument
that the filesystem is always a better place to store image content.
> > There we go... you only think you are right. Thanks for clearing that
> > up. When you have proof of being right I'll start taking notes. At this
> > time I'd like to bring into play a line originally introduced to me by
> > Mr. Tedd Sperling:
> >
> > Locus ab auctoritate est infirmissimus.
> >
> > Thanks tedd, I like that line. When you have something substantial to
> > back up your claim, maybe proof as opposed to argument, I'll be all
> > ears. Your education, your immersion in the field, even your hands on
> > experience do not make you right. They increase the likelihood that you
> > know your subject matter, but in absence of tangible evidence they are
> > only theories.
>
> I have posted a good number of reasons why the position presented is
> correct. You have posted zero refutations to the reasons. It may not be
> "irrefutable" in your eyes, but funny how they have not been refuted.
You have posted a good number of reasons why it is sometimes better,
even more often than not better, you have not posted a single reason the
indicates why it is ALWAYS better. Why'd you skip the second half of my
post where I gave contradictory examples?
Let me spell another out for you, I'll even do it in your language:
User requests a page that requires the assimilation of N icons into a
single larger image as uploaded previous by the user of the current
session (n can be any number of uploaded icons -- all icons just so
happen to fall under 2k in size):
Database Storage:
Get http request
parse request
check permissions
init PHP request
check session validity
create sql request
parse query
execute query
open file (if table not currently open)
lock file for read
grab N items of data based on user ID index field
return data (local socket connection)
unlock read lock
format return data (in memory)
create aggregate image based on image dims (in table fields)
for i = 1 to n
copy sub-image into aggregate image
endloop
set headers for browser
send data
Filesystem:
Get http request
parse request
check permissions
init PHP request
check session validity
open directory for user ID image path
(not sure but I think you need a read lock)
read directory
(maybe release lock)
close directory
for i = 1 to n
open image file
(not sure but I think you need a read lock)
read in image content
(maybe release lock)
close image file
temporarily store image content
endloop
create aggregate image based on image dims
for i = 1 to n
copy sub-image into aggregate image
endloop
set headers for browser
send data
Now which one did you say was faster? Which did you say was more
convenient? Which is more understandable by future developers? Which is
more scalable 00 maybe my images aren't on just this one server maybe
they're on 10 servers? By the way, maybe I also want descriptions for
each image imported as part of the aggregated image. So I need to do a
query for those anyways, or maybe you'd use files for that too -- after
all don't files store data? Anyways, you are plainly wrong in the
general case of filesystems being better than databases. They may be
better often, but not always.
Understandably you will argue against this with some artificial argument
such as "it's an artifical example", but really, who cares? You said
never, so artificial examples count. You'll probably still argue (that's
your closed mind getting in the way again), but I'll probably just
ignore you now since I don't think you have anything to add that you
haven't already stated, and you still haven't been able to prove the
argument in general.
I'll tell you what, I'll give you one last chance to prove it. Take the
above example, implement your filesystem method for 10000 icons and I'll
do the same using a database. Then we'll benchmark them. And yes, I do
want associated descriptions embedded in the aggregate image. If you are
so right, then this should be trivial.
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
