Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Re: Re: J2EE is too complicated - why not Perl?

by BrowserUk (Patriarch)
on Dec 07, 2003 at 15:20 UTC ( [id://312923]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: J2EE is too complicated - why not Perl?
in thread J2EE is too complicated - why not Perl?

Thanks for taking the time to give such a comprehensive answer. I'm not completely convinced by it yet -- but that's probably no surprise:) I started writing a blow-by-blow counter argument, but stopped as I decided you probably would not be interested in reading it, and that this may well be considered too far OT for this place.

Some parts of your post read a little like "I have a relational hammer, so the whole world looks like a Codd defined nail":) Please take that in the humourous manner in which it was intended. If you do have any interest in looking at an alternate viewpoint, you might like to read The OODBMS manifesto. The word "manifesto" kind of put me off reading it the first time I was refered to it, but I bit the bullet and read it anyway and was glad I did. It's not a that long. A hour or so should do it as a first pass.

The following is what I had written before I stepped back a little. I include it only as an "if your interested" sample of my thinking.

IMO, most of the advantages that you cite for RDBMSs are denatured by the need to force fit the mapping of objects to a relational view.

For example, atomic transactions. The simple act, from the view of the OO-programmer, of modifying a single instance of a single object, becomes a nightmare to translate into an 'atomic transaction' via SQL, if that object is a compound object. Even if our objects are limited to single inheritance, the object in question may be a subclass of a subclass, and may contain one or more collections (sets/bags) of a couple of other object types. Saving a single instance of this object to an RDBMS would require modifications to at least 4 tables to be done as a single transaction, but the nature of the way objects are constructed (in the memory of the application) means that 4 different classes will be involved in that transaction, each performing it's own constraint checking and exception handling. Often as not, the four classes will be written and maintained by 4 separate programmers.

Building all the code for each of these four classes into a single executable and coordinating the DB access to atomise the transaction is awkward to say the least. That the very next application using the same top level class has to perform the exact same juggling act is wasteful of effort.

Now sublass this class and try to save an object of this new class? The atomicity of the transaction at the superclass level is wrong. We need to move the boundaries of that atomicity up a level to the subclass. Every time we add to the class structure, whether through inheritance or composition, the task of managing the boundaries of the transactions moves also, and must be repeated in every application that makes use of the class.

The only effective, reusable way of avoiding this is to place the code that performs the updates of individual classes/tables within the DB itself, and have the DBM manage the transactions for us. In other words, we need to be able to tell the DBM, "store or update this object instance", and have it trigger the sequence of updates required, treating the whole sequence as a single transaction.

With respect to using an SQL client as a debugger. Did you ever see the mess that results from (wrongly) modifying the contents of a complex C tree or list structure in memory using a debugger? You tweak a pointer somewhere to see the effect of your proposed correction to a bug your tracking down and get the alignment wrong. You type the "go" cmd to restart the application and all hell breaks loose:)

The problem is that, using SQL to view and modify a compound object in terms of it's consituent tables rather than as a complete object is so fundementally dangerous -- in the same way as tweaking pointers in memory. The difference is, that tweaking memory pointers only screws up the transitory data held in memory, whereas doing it to bits (tuples) of objects in your DB is likely to screw up the permenant state of your data.

And that's my point. Viewing, and being able to view, the component parts of compound objects as individual tupples held in disparate tables, and modify them is exactly the same as being able to modify tables whilst bypassing their relational (foriegn key) constraints -- it is so dangerous, that it simply should not be possible to do it.

With respect to the physical storage and performance. Giving the programmer an OO view of his OO data does not preclude using an efficient (tabular/tupple) based physical storage mechanism. It simply hides this from him and places the code that manages the mapping, contraint checking and transactioning from him, and places the logic for doing it in a single, central place where it can be got right once and optimised in one place, rather than spreading it all over every application and requiring every programmer to understand and recreate it over and over again.

This is a long time mindware project of mine. I first read Codd's original 1970 paper, in 1976 as part the preparation for my end-of-term project. I didn't understand a lot of it back then, but down the years I've understood more. I've been a long time proponent of RDBMS's, but for the last 5 or so years I've begun to see the need for something more. That's not to say that the underlying tenants of relational logic have changed. Only that the programmers view of them should.


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

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: J2EE is too complicated - why not Perl?
by autarch (Hermit) on Dec 09, 2003 at 06:25 UTC

    Some parts of your post read a little like "I have a relational hammer, so the whole world looks like a Codd defined nail":) Please take that in the humourous manner in which it was intended. If you do have any interest in looking at an alternate viewpoint, you might like to read The OODBMS manifesto. The word "manifesto" kind of put me off reading it the first time I was refered to it, but I bit the bullet and read it anyway and was glad I did. It's not a that long. A hour or so should do it as a first pass.

    In response to this, and some other OO manifesto thingy, Chris Date and Hugh Darwen wrote The Third Manifesto, which details what a truly relational DBMS should provide. SQL does not adhere to relational theory, and so comments to the effect of "I've used relational DBMS's and they don't do what I need ..." are incorrect, because AFAIK there are no truly relational DBMS's.

      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!

        The primary author of the dbdebunk website places quotes he considers to highlight issues in understanding of the relational model by the unwashed. Fabin Pascal hates OODBMS and considers the whole of OO to be a dead end in computer science that should have been aborted awhile ago. He links to several sites critical of OO. He does bring up several issues that makes you think and he should be read, but all he says should be taken with a grain of salt. My personal experence with OODBMS is that they do under load grow very slow, much slower then a equally loaded RDBMS(or as Pascal would rather put an SQLDBMS)
        MADuran (who forgot his password)

        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.

        That's a bizarre attitude. So you have something against theoretical physics? There's nothing wrong with theory. It's useful. If the theory has yet to be implemented, that's not necessarily a condemnation of the theory.

        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.

        Actually, they've spent 30 years on developing SQL DBMSs. Unfortunately, for whatever reason, SQL became the standard way back when (in the 70s), presumably because it's "simple". And since, in comparison to what came before it (network & hierarchal DBMSs), SQL is indeed a huge improvement, it quickly became the dominant player in data management. That strongly discourages the creation of a truly relational DBMS, since it could not be 100% SQL-compatible. Market forces being what they are, the big 5 would rather spend time and money on more sure things, despite the technical problems.

        Anyway, I'd strongly suggest reading The Third Manifesto. If you don't want to buy the book, reading most of the articles on Database Debunkings will introduce many of the same ideas.

        I should also point out that I think Pascal's tone is terrible. It's too angry and condescending, which turns a lot of people off. Nonetheless, the technical content is excellent. Too bad he doesn't seem to understand the old adage about flies and honey.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://312923]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2024-03-29 11:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found