Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

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

by etcshadow (Priest)
on Dec 07, 2003 at 07:12 UTC ( #312873=note: print w/replies, xml ) Need Help??

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

I realise that RDBMSs are well-tried and easily (if not always cheaply) available, and most OODBMSs are little more than a less than complete veneer over an underlying RDBMS, but is inconceivable to have an object store that doesn't rely upon mapping to a relational DB engine?

That's a great question. I tend to think that relational databases really are a great tool. The thing that makes them so good is that they are both very powerful and very capable. This stems from the fact that, conceptually, they map quite well to the constructs we need in software and that the hardware demands.

Relational databases organize data in a way that allows it to be efficiently managed on real physical data stores (hard disks and hard disk arrays). Think about how a full-table-scan translates to a sequential read off of a spinning disk. Think about how a table with a fixed structure can easily be translated into a fixed-width record and to blocks and sectors on a disk, and so on and so forth (lots more examples... but for the sake of being concise, I'l leave it there). The point is that the structure itself does a wonderful job of abstracting away the hardware, but in such a way that doesn't hide any of the best capabilities of that hardware. In short: they make a great abstraction of the physical persistence layer to your application.

Likewise, what they provide to your application for the purpose of persistence is about the best that can be provided without trying to do too much (and, thereby, doing it poorly and/or making life hard for programmers). If you're not convinced that doing more for applications than they do would be problematic, just look at how much of a mess most object-relational mapping frameworks are. Also (on that note) if the object relational mapping were done at the persistence level, yielding you an object-store rather than a data store... well, then you'd be in a situation like CORBA, which is also proof by counterexample.

There's two halves to saying that it does the right amount, though, and above I only defended the first half, that it didn't do too much... so let me explain why I think that it does enough, as well. Well, think about the data in your applications. In a C-ish world, you have structs, in a java-ish or C++-ish world you have objects' instance data, which is very much like a struct (note: I do not say that an object is like a struct; I say that an object's data is structured like a struct). And what's in a struct? Well, either "primitive" data-types, derived (non-primitive) data types (i.e. other "struct"-like entities). Depending on the details of your language of choice, you may have pointers or references included in your primitive data types or maybe that's how you store other derived data types... but take it as a given that you also (perhaps inclusively) have references or pointers involved as well. A relational database gives you table definitions, which are like struct typedefs, or like class definitions, or what have you... but the point is that they parallel how you declare your application's data structures. In those table definitions, you put primitive data types (numbers, character strings, dates) and you put references to instances of other (or the same) derived data types (i.e. tables). These, in the RDB world, are of course called "foreign keys".

Anyway, summary of that long paragraph is that RDBs give you what you need to model your application data in the form of:

  • typedefs / class defs => table defs
  • (non-pointer-) primitives => (duh) primitives
  • pointers / references / included derived types => foreign keys
  • structs / instances => rows
And I know that's kind of elementary, but I'm still spelling it out for the sake of completeness.

Last of all RDBs give you things for free, that you're likely to end up wanting, regardless. To name a few:

  • Visibility into your application's state, and the ability to manipulate it. A sql client is like the world's coolest debugger!
  • The ability to make arbitrary reports on your data. For any kind of real business application, this is invaluable. If you weren't using some kind of database for your data, you'd end up having to write a reporting framework, and you wouldn't be able to do it as well.
  • Performance: I know a lot of new programmers think they can do better... but again, even if you could, it would be a hell of a lot of work you don't want to have to repeat, when, with an RDB, all you'd have to do is build an index.
  • I'm sure there's some better example... but it's late and I'm getting tired
  • Update: How could I forget: atomic transactions!

So, to the question, as you framed it: is it conceivable to have an object store that doesn't map to a relational DB engine. Sure it's possible, but I haven't seen much in the way of reasons to do it. The best example I can think of (which I acknowledge as an emerging possibility) are objects in languages, well, like perl... in which you don't necessarily have a fixed object "structure" as you do in java or C++ or C, etc. That is, that the objects are so amorphous that you can't nail down any kind of meaningful "structure" that covers every instance of the class. However, I tend to think of these free-form objects as typically having some kind of structure, it may just be a deeper structure than first appears. Also, there's the issue of subclasses which contain different instance data (and thus define a different structure) than their parents. To that I say: there's almost always a structure that represents the super-set of the structure of all of the relevant, related classes... define your table structure around that, and let the columns you don't need be null.

Anyway... this is a cool discussion, but I'm tired now.

Not an editor command: Wq
  • Comment on Re: Re: Re: J2EE is too complicated - why not Perl?

Replies are listed 'Best First'.
Re: Re: Re: Re: J2EE is too complicated - why not Perl?
by BrowserUk (Patriarch) on Dec 07, 2003 at 15:20 UTC

    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.

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

      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,

        As the current Quote of the Week at 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

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2023-12-10 22:42 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.