> 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. In some other post, I detailed how, but I'll try again. Getting bitmap from a database: Get http request, parse request, check permissions, initialize php request, execute php request, create sql query, parse query, execute query, find data in file, (mysql isam) lock file for read, retrieve data, (mysql isam) unlock readlock, format return data, format data as bitmap file for browser, send data to browser. Getting bitmap from file service like apache: get http request, parse request, check permissions, open file, send file. > >> > 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. Then you haven't been reading. > >> > 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. (new & good) != always > This > happens because they don't get stuck in the mindset taught to them by > the establishment. Ah, "The MAN" argument. "The MAN is wrong." More often than not, the established practices are right. It is typically when revolutionary discoveries or inventions occur that conventional wisdom becomes obsolete. Are you trying to say that storing non-relational data in a relational database is a "revolutionary" idea? > I think you're a bit stuck in a rut with horse > blinders covering your face... Knowledge and ignorance can be indistinguishable to those fully versed in he subject matter. > nowhere to go but filesystem because > you're to closed minded to appreciate novel solutions using databases > *smirk*. What you want to do is hardly novel, it has been tried many times over and the jury has been in for a while. > Personally, I can appreciate both solutions. And I'll just > reiterate, nobody is arguing databases are always better. But they are > sometimes. I would say that they are NEVER the better solution, they may be expedient at times, but never better. > >> >> > 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. Oh please, the "who knows argument." > >> > 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. No,it means it shouldn't. > 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. Yup, who cares. What is this engineering thing anyway? > >> > 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 Thanks for finding that, "database-esque" is not "pretty much are." They share many similar concepts because, hey, computer science works and a good method is a good method when you have the same job, i.e. finding one item from another. File systems and databases are very different in their functional requirements. > >> > 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. 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
