On Thu, 2007-03-01 at 19:42 -0500, markw@xxxxxxxxxxxxxx wrote:
> > On Thu, 2007-03-01 at 21:08 +0100, Roman Neuhauser wrote:
> >> # tedd@xxxxxxxxxxxx / 2007-03-01 12:46:09 -0500:
> >> > At 10:01 AM -0500 3/1/07, markw@xxxxxxxxxxxxxx wrote:
> >> > >In this discussion I have stated reasons why it is a bad idea. No one
> >> has
> >> > >come up with a counter point which can only be served by a database
> >> and
> >> > >thus proves me wrong. I think that says something.
> >> >
> >> >
> >> > Contradiction is not a sign of falsity, nor the lack of contradiction
> >> > a sign of truth.
> >> >
> >> > I think "no comment" says that discussing this issue has problems.
> >> >
> >> > For example, this has been subject of many flame wars before and I'm
> >> > sure that many just don't care to join in. If you want to claim
> >> > something absurd, then who are they to correct you? And why should
> >> > they care?
> >>
> >> Exactly, ted. markw is so obviously right, and he's presented the
> >> points so well, there's nothing to add, really. but since you asked:
> >> yeah, he's right.
> >
> > I'm going to skip his response to my previous comments and just add the
> > following to this post:
> >
> > To follow up with Ted, nobody said using the filesystem is bad,
>
> No, it is the most efficient way.
Prove it! Don't just claim it.
> > what
> > many of us are saying is that the database is not necessarily bad
> > either.
>
> To make this claim, you need a rational argument to support it. "Faith
> Based" engineering is a por substitute.
>
> > It really depends on what you're doing and how you choose to
> > address the problem with all of your knowledge.
>
> Assuming your knowledge never expands when confronted with a problem which
> requires learning more.
>
> > Many of us here are
> > quite aware of the different technologies available to access shared
> > binary data across some kind of network etc. But, given time
> > constraints, budget constraints, and all manner of personal preference
> > and training and ingenuity, we CHOOSE to use one solution over the other
> > for any given problem space.
>
> The "good enough" fallacy.
>
> > So far Mark has almost entirely focused on
> > the performance and "filesystems were made to do that" argument...
>
> Um, yea.
>
> > Who the hell cares??!
>
> Ahh, famous last words. You only need to get bitten once and you will
> change your tune very quickly.
Oh, those aren't my last words, and I'm hardly famous. And why would I
change my tune quickly? And wouldn't that depend on what bites me? I
haven't heard anything from you yet that suggests you are right and I am
wrong. I've heard anecdotal arguments in favour of the filesystem for
some cases, but nothing that proves it is the flat out winner in all
situations.
> > If people stopped trying to use old ideas to solve
> > novel problems then innovation and ingenuity would go out the window...
>
> I would argue that if people fail to research and devise better solutons,
> then innovation doesn't happen.
Many new ideas come from people not versed in previous solutions. This
happens because they don't get stuck in the mindset taught to them by
the establishment. I think you're a bit stuck in a rut with horse
blinders covering your face... nowhere to go but filesystem because
you're to closed minded to appreciate novel solutions using databases
*smirk*. Personally, I can appreciate both solutions. And I'll just
reiterate, nobody is arguing databases are always better. But they are
sometimes.
>
> > and if that happens, then nothing advances, nothing is doscovered, we
> > live a life of boring old filesystems that just do "files".
>
> So, files are "bad?"
No, but they may not be the best solution. Who knows, humans are a very
young species and our knowledge has only begun.
> > Why CAN'T a
> > database be used as a filesystem?
>
> Because it is not well suited for the task for which you are trying to use
> it.
Just because something isn't generally well suited doesn't mean it can't
be used. You seem to think that everyone needs to follow your way.
Wrong, we'll follow whichever way we think is better given our own
experience.
> > Mark said himself that filesystems
> > pretty much are databases..
>
> I said nothing of the sort. I forget the exact words, but yes there are
> conceptual similarities, but that's the limit of what I have said.
And I quote:
Rob said:
> In fact many newer bleeding edge filesystems are practically
> database implementations.
Mark said:
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.
"database-esque" -- straight from the horses mouth :B
> > why limit them to just doing what they do
> > now? Why can't they do more?
>
> Because a database *is* designed to do more than a filesystem. Databases
> have a LOT of features and requirements that file systems do not have and
> things like bitmap binary objects don't need. They are fundamentally
> different things.
>
> > Why can't they become more like fully
> > fledged queryable databases?
>
> See above.
What precisely should I see above that lends credence to a counter
argument?
> > Why does Mark think he's more right than
> > the many people on this list?
>
> I think I'm right because I've been down this road a couple times, and
> have done a lot of research and can defend the position.
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. Think about this... there are thousands of physicists,
and several theories on space/time/existence. And they don't all believe
the same theory even though they are all experts *lol*. This suggests
many highly respected physicists are wrong. Extending this to your
argument... you may be wrong. I'm not saying you are, but I will say
it's extremely likely, because you haven't allowed for any instances
where the database is better -- as such your THEORY encompasses the
entire problem space and is unlikely to hold. In fact, someone already
gave a counter example where your theory is incorrect:
Richard Lynch said:
If the image is tiny enough (think an icon), and the other
data that you HAVE to fetch on the page is large enough,
then the image itself may be small enough to be cheaper to
pull through the DB rather than an extra fstat.
This is an edge case in a niche situation, but it's there,
and there's a benchmark in the archives proving it.
There, now you're just plain wrong. This single counter example brings
down your all encompassing argument,
> > What evidence has he given that says filesystems are ALWAYS, IRREFUTABLY
> > the best option?
>
> I'll give you a few facts to think about:
>
> (1) If the binary object is stored as a separate file (as in a lot of
> databases) then there is no advantage to storing the binary data in the
> database.
So what? Please show how this addresses "What evidence has he given that
says filesystems are ALWAYS, IRREFUTABLY the best option?"
> (2) If the database uses an internal block cache, the binary data will use
> up more blocks and cause the database to be less efficient.
This is an efficiency point. We're not just talking about efficiency as
has been stated many times. At any rate please tell me how this
addresses "What evidence has he given that says filesystems are ALWAYS,
IRREFUTABLY the best option?"
> (3) On MySQL, with MyISAM, the table is readlocked when data is being read
> from a table. If you store bitmap data in the database you will have
> longer locks on your database and overall capacity will be diminished.
MySQL is a specific implementation (cue sound of wrong answer from
Family Feud *MMMMMMMMMMMMMMMMMMMMP*). At any rate, could you please show
how this addresses "What evidence has he given that says filesystems are
ALWAYS, IRREFUTABLY the best option?"
> (4) The data in a bitmap does not need to be evaluated for joining or
> selection, storing it in the database is an expense for no reason. The
> metadata of the bitmap, size, filename, datestamp, etc. are more usable
> and take up less space.
See now, here's another place where your argument breaks down. What
about mime-type? What about file descriptions? Tagging? And verious
other meta data? In a database there's proximity of information. You'd
need to do two lookups for all this information. First the database,
then the filesystem. In one query I can get it all. Not only can I get
it all, but I can get multiple hits matching a query in a single
request. You need to grab each file individually incurring all the
overhead of opening, reading, and closing individual files each time.
Another crack in your theory exposed.
> > He cannot, anything
> > he argues in favour of the irrefutability of his argument only needs one
> > counter example.
>
> Which, somehow, you've failed to provide.
Examples above. I need no more, a single example is enough to prove you
wrong since you took the extreme position of saying your assertion was
universally true.
> > Unlike our argument, he must prove the all encompassing
> > nature of his solution space.
> > We only need to prove a single example.
> > The onus is on Mark to prove his argument is irrefutable, not on us to
> > prove that database are always better, because we have never made that
> > claim. I now await the book from Mark describing how filesystem storage
> > for every single binary storage problem ever encountered and ever to be
> > encountered is the solution.
>
> Nice strawman,
From Wikipedia:
A straw man argument is a logical fallacy based on
misrepresentation of an opponent's position. To "set up a
straw man" or "set up a straw-man argument" is to create a
position that is easy to refute, then attribute that
position to the opponent. A straw-man argument can be a
successful rhetorical technique (that is, it may succeed
in persuading people) but it is in fact a misleading fallacy,
because the opponent's actual argument has not been refuted.
I didn't attribute the position to you, you took on your viewpoint that
"databases are always better". As such I merely pointed out your
responsibilities to defend that position. A strawman argument would
entail associating you with a position you did not claim.
Allow me to refresh your memory:
Ted said:
> It's clear enough to me that it's not a bad idea -- it depends
> upon the purpose.
Mark said:
Obviously, I don't agree.
As such you are saying it does not depends upon the purpose.
Rob (me) said:
> To follow up with Ted, nobody said using the filesystem is bad,
Mark said:
No, it is the most efficient way.
So obviously the filesystem is the "most" efficient way... you need to
prove that -- not just say it. Although, I'll give you, you wrote that
after I called you out. But it was sufficient for you to say the
previous quote in response to Ted. That was where you left a reasonable
argument of the pros and cons of each method and entered the TwiMark
Zone.
> but the actual question is this:
>
> Where do you store bitmap images? In a database or in the file system? the
> answer is the file system for the reasons provided.
Actually, following is the actual question:
Alain Roger said:
Hi,
i stored all my pictures in my PostgreSQL DB as bytea type.
Now i would like to know how can i display them in my PHP pages?
where can i find some example ?
Thank you. Please feel free to continue your baseless argument when you
have found some real proof, have learned to check your facts, understand
your critical thinking references, and have validated the heatsink and
fans around your brain are working correctly. You might want to switch
to a liquid cooling system. I highly recommend a dark ale or two to
bring down the core temperature :)
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
