On Mon, 2007-03-05 at 14:48 -0500, markw@mohawksoft.com wrote:
> > On Mon, 2007-03-05 at 10:16 -0500, Mark wrote:
> >> Alain Roger wrote:
> >>
> >> > Hi,
> >> >
> >> > It's amazing that my previous post has raised so much consideration
> >> about
> >> > the fact to store or not pictures into DB.
> >>
> >> And yet you ask again!? Did you not learn? No good can come from this
> >> question.
> >
> > He didn't care about the debate. He is already using a database and
> > wants to display the images. I'm sure he learned plenty, but not what he
> > wanted to learn.
>
> "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, and that presumes
there's an afterlife that does not have the restrictions of our
currently reality. 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."
Me
> > I'd say the most important outcome of the side-track
> > debate was to clarify that it depends on what you are working with, what
> > you are doing, what your tolerance is for various types of solutions,
> > and where those tolerances lie. An important thing we also learned, is
> > that while filesystem storage is often the better solution, it is not
> > always the best solution, especially when factoring in such things as
> > convenience and simplicity.
>
> I don't think we came to any such conclusion. I still assert that while
> there may be multiple "right" ways to accomplish a task, there are often
> clearly "wrong" ways. Putting bitmap data inside the database is a
> mistake.
By "we" you mean "you" and perhaps some other edge believers.
> Before y'all got hyper-literal trying to argue the finer details of the
> definition of "mistake," my assertion is this:
>
> 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. 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.
> 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.
> 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.
> 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?
> 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. You have chosen to ignore them. 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
> >> > 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.
> [snip]
>
> >
> >> 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.
> > 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.
> This is engineering, not art class. There are ways to evaluate solutions
> as being better than others.
This is computer science, not engineering. There are considerations for
one approach over another not necessarily confined to your idea of
"efficiency". The problem encompasses time, space, economics, and any
number of other dimensions.
> [snip]
>
> >
> >> > So please, how can i do to display pictures from DB, when my PHP page
> >> also
> >> > include texts and other images (from filesystem) ?
> >> >
> >> > In fact i would like to do something like a thumbnail...
> >>
> >> You will need to repeat the same steps outlined above, but use image
> >> manipulation utilities to reduce the image. Again, that's why you store
> >> images in files and not in the database.
> >
> [snip]
BTW as another point for the irrelevance of your argument, the
filesystem and the database storage solutions have the same algorithmic
complexity, namely they are both O( lg n ).
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
