Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Thanks for the link. I will pursue follow up on it vigorously.

It seems that the guts of the argument is only available by purchasing a book -- which makes me a little suspicious --, but various snippets and stuff I've run across whilst trying to track down further information have intrigued me enough that I will be adding the book to my list.

It looks like it will be interesting to track the two sides of the argument through and see which one wins out in the long term. Unfortunately, it looks like the long term is likely to be really quite long:(

Trying to track down further information I did come across this rather pertinent quote.

I use relational databases in my work every day. Bricolage of course runs on PostgreSQL, and I've done some work on DBD::Pg. But after using various RDBMSs over the years (Access, MS SQL Server, DB2, MySQL, Oracle, PostgreSQL), I've come to one inevitable conclusion: RDBMSs are all just total crap. Don't get me wrong, I think that they have their place. I just don't know what that place is. But no decently designed object system that I've worked on (let alone a poorly designed system) has found an elegant way to interact with databases. Sure, DBI makes things easy for Perlers in that it provides a pretty standard, uniform interface for accessing databases of all kinds. But if you're designing even a moderately sophisticated application, you still run up against the complete incompatibility of object-oriented design and relational storage. They're just completely orthogonal to one another. --Online Exchange, http://use.perl.org/~Theory/journal

As the current Quote of the Week at www.dbdebunk.com. I'm not sure if it is being quoted as a good or a bad example, but it is at least good to know that I am not entirely alone in my thoughts that RDBMSs and OO are not a good fit.

It is quite possible that I fit into one or more of the categorise of people described by this snippet from apro true relational model wiki

Drawbacks: It's never been fully implemented. This is by far its biggest handicap. In spite its simplicity, it's likely you'll find lots of developers, architects, DBAs, book authors, committees who have no clue, but pretend that they have. After all, it would be quite embarrassing for someone to admit that he doesn't know what the RelationalModel is. The fore mentioned category of people who have no clue usually enlist a ton of invented drawbacks like: it has limited expressive power, doesn't support "complex data models", joins are slow, doesn't support navigation, doesn't support complex and/or directional "relationships", doesn't support object identity. Number 1) and 2) usually generate a vicious circle, because DBMS vendors react to what the market demands and spend money and time implementing purportedly useful extension, which are in fact not only less useful than having a true implementation of the relational model, but they are actually harmful. These extensions tend to be generically called Object/Relational features.

In which case, it may well be that despite my years of trying to understand them, I have allowed my judgment to be impaired on the basis of my experiences with trying to make those RDBMSs that exist now, and the features they offer and the awkwardness that I have encountered on trying to use them in the OO context, to influence my judgment about the Relational Model too hastily.

It may well be that I am simply incapable of understanding the full implications of Codd's vision, and that the current big 5 implementations of that vision are nothing more than half-hearted attempts at it driven solely by commercial need/greed rather than Relational purity.

None the less, by their own admission, there are no pure Relational Model DBMs available, and so my judgment is based upon my experience of those things that do exist. It could not be otherwise. I tend to be extremely suspicious and slightly dismissive of "theoretically pure" arguments and propaganda in general. Until I, as a run-of-the-mill coder am given the opportunity to use a practical implementation of such theories, they are nothing more than that, in the practical sense.

Whilst it may be true that given a real-life implementation of the full Relational Model, as so insightfully envisioned, and mathematical proved by Codd, that the problems I (and others) have encountered trying to utilise those apparently poor substitutes that currently exist might disappear.

However, a large number of very clever people have put the best part of 30 years getting RDMBSs to where they currently are. Whilst some of the marketing decisions taken may have been done on the basis of commercial greed and/or in an absence of a full understanding of the pure Relational Model, not all those that worked on all the current implementations will have been totally ignorant of, nor blind to the theoretical goals.

That, despite all their combined efforts, huge amounts of money and the considerable amount of time that has passed, there is still no True Relational DBM available, for money nor love, tends to indicate (to me at least) that maybe that model is too grounded in its mathematically provable, theoretically correct high place. That maybe today's computers, or maybe your average Joe Coder are simply not ready or capable of implementing that ideal. There are other examples of such theoretical, technical ideals that human kind hasn't yet succeeded in reaching. The one that comes to mind is the Nuclear Fusion Reactor.

In the meantime, your average Joe Coder has his daily task of trying to earn a living, producing systems that work now (and are usually wanted yesterday:). It's inevitable that he will continue to use the best substitute that is available now. And he will continue to utilise, possible flawed, practical approximatations to "full understanding" of the relational model in order that he can make use of the RDBMS. If that means that his practical approximation is less than a full understanding and places him in that "...fore mentioned category of people who have no clue...", then he, like me, will probably accept that condemnation openly, in the knowledge that he is almost certainly one of a great many like him. In fact, I would say that he is probably in the majority.

Whilst it may well be that there are a small group of people that "know better". One has to wonder why they are busying themselves writing books and presenting lectures, lauding their superior knowledge and decrying Joe Coders lack of understanding, rather than implementing the full Relational Model in a practical, usable product?

Update: After posting this, I came across this artical]. The artical sets out to explain why there is nothing wrong with the Relational Model and why all the things that people claim are wrong with it are simply the miunderstandings of the misinformed masses. However, it does, through it's tone, words, conclusions and context, illustrate exactly why I am actively dismissive of those that expound this view -- much better than I ever could.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!


In reply to Re: Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl? by BrowserUk
in thread J2EE is too complicated - why not Perl? by beamsack

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2024-03-28 14:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found