> 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. > 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. > 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. > 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?" > 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. > 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. > 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. > 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. > 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. (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. (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. (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. > 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. > 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, 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
