On Mon, 2007-03-05 at 17:08 -0500, markw@mohawksoft.com wrote:
> > On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote:
> >> > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote:
>
> >> "I gained nothing at all from supreme enlightenment - and for that very
> >> reason, it is called supreme enlightenment"
> >>
> >> Buddha.
> >
> > "Supreme enlightenment is only possible after death,
>
> That depends on your philosophical underpinnings I suppose.
> "Enlightenment," is an interesting topic, one I'm pretty sure goes WAY off
> topic on this list.
Nah, on this list almost anything goes. Even futile opinion pieces
purporting that filesystems are necessarily better than databases for
storing images.
But at any rate, my thoughts on "Supreme Enlightenment" would be "All
knowing" since anything otherwise wouldn't be quite "enlightended". As
such, that would require more bits to encode as knowledge than materials
exist in the universe to encode the knowledge... and even then those
bits themselves would need to be accounted for.
> > and that presumes there's an afterlife
>
> Assumptions without proof do not a logical argument make.
I keep telling you that.
> > that does not have the restrictions of our currently reality.
>
> Most people don't even know what reality is.
I never claimed to know what it was, I'm only making some guesses with
what little I presume.
> > Once you're dead, I highly doubt anyone's is going to
> > care about your filesystem argument (or my counter argument for that
> > matter). Besides, everyone knows God stores reality in a database. All
> > your images belong to him."
>
> As an atheist, I store god in the bit bucket, where [s]he/it belongs.
As an atheist why do you bother stumbling upon the gender issue? Why
even assign a gender?
> >> I have yet to see one implementation or strategy where putting bitmap
> >> data
> >> in a database can not be accomplished more efficiently using a different
> >> approach. Bitmap data does not belong in a SQL database because it is
> >> not
> >> something that is of any use to the algebraic relational syntax of SQL,
> >> thus it is more efficient to store a reference to the data rather than
> >> the
> >> data itself.
> >
> > Image data can benefit from proximity to meta data that describes it
> > that is in a relational database.
>
> This is a false assumption. What possible benefit is gained?
That's not an assumption, it's a fact. If I've already accessed a
location on the hard drive where the meta data exists, and the binary
data is beside it, then I can retrieve the binary data quite likely
without another seek. As such, the time to retrieve is decreased and I
was going to retrieve the meta data anyways. Using the filesystem, where
the data is not in any kind of proximity would suggest a seek (not
withstanding caching).
> > You incorrect presumption is that one
> > would want to make some kind of algebraic query against the binary data
> > itself, when in fact quite often we merely want to retrieve the data due
> > it's relevance to some other field upon which a query has been made.
>
> Apart from a misunderstanding of what I wrote in your first sentence, the
> rest reads correctly.
>
> The functionality can be as easily implemented and more efficiently using
> references instead of the data.
Sounds like you want to make a database out of a filesystem. Once again,
as I've mentioned numerous times, there is little your file system
implementation can do to make the following a more succinct piece of
code:
<?php
$conn = DbConnect();
$query =
"SELECT "
." name, "
." mime, "
." image_content "
."FROM "
." user_images "
."WHERE "
." id = ".DbQuote( $imageId )." "
." AND "
." owner = ".DbQuote( $ownerId )." ";
if( DbQuery( $conn, $query )
&&
DbNextRow( $conn ) )
{
header( 'Content-Type: '.DbField( 'mime' ) );
header( 'Content-Disposition: attachment;
filename="'.DbField( 'name' ).'"' );
echo DbField( 'image_content' );
exit();
}
header( 'HTTP/1.0 404 Not Found' );
?>
> >> Putting database data in the database needlessly increases load on the
> >> database. If you are using MySQL, the tables in which the bitmap is
> >> stored
> >> are read-locked during the read of the data. If the data is large, it
> >> can
> >> use up buffering resources otherwise used to increase query performance.
> >
> > Putting image data on the filesystem when it has related fields in the
> > database needlessly increases the load on the complexity of the
> > application.
>
> Please explain how. You have to put a reference in the HTML stream for a
> later HTTP request from the browser anyway. Where is the complexity coming
> from?
Development.
> If you upload an image to the web server, it is stored in a temp directory
> and must be moved. I find it difficult to quantify any real added
> complexity between a file system move and a database insert.
That's insertion. What about retrieval, deletion, and backup?
> >> Bitmap image data can not be incorporated into the HTML stream with the
> >> rest of the data retrieved. A reference must be created in the HTML
> >> document so that the client web browser can issue a new HTTP request for
> >> the image. It is more efficient to put a reference in the database and
> >> have the browser query directly for the image against a file based
> >> system.
> >
> > Filesystem data cannot be directly incorporated into the browser request
> > when a custom authentication system is in place that requires wrapping
> > the file request in a PHP script. Your argument keep going back to the
> > same refuted point. YOU CANNOT ALLOW DIRECT REQUESTING OF SENSITIVE
> > DATA.
>
> No need for caps. There are many better ways of implementing authorization
> to access images.
>
> One could store in the local session data a variable "allowed" =
> "/images/filename" and rerieve the image. That way it authenticates
> locally and saves a database hit. The PHP file can simply do an fopen of
> the bitmap and send it back.
How do you know the filename is allowed when the authorization is
determined by membership in a group for which the file has been
registered as accessible to that group? You can't just pre-flag it until
such time as you do the work to resolve the authentication permissions.
What happens if the permissions change during the lifetime of the
session? You now have unauthorized accesses to an image due to stale
permissions. The database doesn't need to do an fopen if it retrieved
the image along with permissions in a single query using a join. Also
now what if they're navigating thousands of image thumbnails? Are you
going to store in the local session all these pathnames and possibly
stale permissions?
> >> SQL databases don't use normal data access methods to access large
> >> binary
> >> data, in PostgreSQL TOAST is used, in MySQL they are read as their own
> >> data blocks, and in Oracle they are sometimes put in different table
> >> spaces. Anyway you slice it, they are less efficient than normal "data."
> >
> > Once again you speak of one kind of efficiency. There are many kinds of
> > efficiency when practicing computer science. Probably you think we
> > should go back to directly programming in 1's and 0s because the
> > efficiency of the code is superior to that generated by a higher level
> > compiler. Puhlease. Did you actually study computer science?
>
> You didn't actually address the subject, you merely made an absurd claim
> that I would say something stupid and called that debate.
I've addressed the subject matter all along. You on the other claim one
thing without any real evidence to prove it.
> I did in fact, study computer science, and besides a few software patents
> and published writings, I study constantly and get paid to advise.
Oh here we go again... yadda yadda I've written software patents, I have
published writings, I study constantly and get paid to advise -- these
do not make you correct. I have a degree in computer science, can't say
I care for software patents since they choke the lifeblood of
innovation, I publish comments to this list all the time, and I get paid
to advise AND write real world applications -- who the hell cares. These
don't change the argument at hand.
> So, are you going to actually debate, or simply ad hominem through this?
Ad hominem?? Do you even know what that means? Please indicate to me
where I used an ad hominem? Asking you if you studied computer science
was a legitimate question since you made claims to it and yet you seem
to sidestep actually answering anything related to it. Such as how my
comment on the algorithmic complexity is oddly missing from your
reponse. I've noticed how you conveniently omit in your responses
anything that would require a real answer. Chances are you're just
trolling, but I'm happy to take the bait.
> >> If you can't come up with a scenario that disproves the previous
> >> assertions, then you aren't arguing the point and creating strawmen in
> >> an
> >> effort to avoid the real issues.
> >
> > I've come up with plenty of examples.
>
> None that actually show a need. An alternate implementation that is
> provably less efficient does not disprove he assertion.
It disproves the general assertion (especially since you originally said
the filesystem is always better, then you conveniently backtracked and
said "almost always", then you indicated to the poster of the original
question that they seemed to have learned nothing because they chose to
continue using the database as their storage repository -- my my, you do
seem a little flakey in your position).
> > You have chosen to ignore them.
>
> Absolutely not, I analyze them and tell you why they don't work as well.
You have not yet given me any proof. You have given anecdotal argument,
none of which proves your position.
> > I
> > also left an open challenge to you on an implementation basis that you
> > have yet to accept. Feel free to study up on self-deception. Your
> > critical thinking appears to fall into this category:
> >
> > http://en.wikipedia.org/wiki/Self-deception
>
> I apologized earlier for coming off as a wise ass, and I now remember why
> I did that. Discuss the facts and methods please.
The fact is, I can gain better performance using solely the database in
some cases. I've offered up a challenge to you to disprove that. You
have yet to accept. When will you stop sidestepping your opportunity to
prove me wrong. I don't think you will, because you know you won't win.
> >> >> > However, none of those posts answered to my question... How can i
> >> >> retrieve
> >> >> > and display those pictures to my PHP pages ?
> >> >> >
> >> >> > Basically, on my PHP page I have some texts and I would like to
> >> >> extract
> >> >> > from DB the pictures to display.
> >> >> > Therefore, set the header to mine JPEG or GIF does not allow to
> >> have
> >> >> text
> >> >> > also.
> >> >>
> >> >> This is another problem with images in databases, unlike text or data
> >> >> which
> >> >> can be incorporated into the HTML output stream, an image needs to be
> >> >> its
> >> >> own file.
> >> >
> >> > Image doesn't need to be it's own file,
> >>
> >> Again, don't get hyper-literal, by file, as used in this post, I meant
> >> file as seen by the browser which is represented by a URL and causes a
> >> HTTP request.
> >
> > Again, please stop being hyper ignorant. Your files require an http
> > request even when not protected by any kind of authentication. And when
> > they do require authentication, then quite likely they require a
> > wrapping PHP script (or other scripting language) and access to the
> > database server to determine the validity of the authentication.
>
> Using a PHP script to verify authentication is a good way to accomplish
> the task, but that has nothing to do with storing bitmap data in a
> database.
It has plenty to do with storing bitmap data. See my previous comments
on proximity.
> >> >> You will have to hit the database twice. Once to render the page, and
> >> >> again
> >> >> to render the image.
> >> >>
> >> >> To render the image you need to query the database and send the data
> >> >> back on
> >> >> its own, but before you do, you have to set the content type header
> >> to
> >> >> jpeg, gif, or whatever.
> >> >>
> >> >> This is why I say image data does not belong in the database.
> >> >
> >> > Boooooooooooooooooring.
> >>
> >> Actual answers to actual problems are usually boring.
> >
> > No, what is boring is they way you reject anything that challenges you
> > and pretend to not have heard of any evidence to the contrary of your
> > argument.
>
> Statements are not evidence, statements verified to be accurate are.
I have yet to see verifiable evidence for the accurateness of your
claims. I will accept code benchmarks and mathematical proofs. You have
provided none of these to this point.
> >> > Belongs wherever the developer or the business
> >> > requirements want to store it.
> >>
> >> Yea, and 1+1 = what ever the engineer or the business requirements want
> >> it
> >> to be, right?
> >
> > Once again it depends. What base are we working in? Are we working in
> > some kind of odd algebraic space? 1+1 only equals 2 in specific
> > situations.
>
> And that shows the depths of your participation in this discussion. There
> is a canonical meaning to words, phrases, and expressions. When one does
> not wish to listen, one merely ignores these making productive discussion
> impossible.
Yes, I've noticed that you ignore entire passages of information. You
say you "analyze" them and refute them, and yet so often I see no
response, and no argument. Once again I say you are immersed in
self-deception.
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
