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

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
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

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

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

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others imbibing at the Monastery: (11)
    As of 2017-03-27 20:53 GMT
    Find Nodes?
      Voting Booth?
      Should Pluto Get Its Planethood Back?

      Results (324 votes). Check out past polls.