Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Theory (10)

  (email not shown publicly)
AOL IM: dwTheory (Add Buddy, Send Message)
Yahoo! ID: dew7e (Add User, Send Message)

Perl, PostgreSQL hacker; US politics junkie; Webapp developer; Portvangelist; profane iconoclast.


Journal of Theory (10)

Monday May 05, 2003
09:28 PM

All RDMSs Suck

[ #12028 ]

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.

Many have tried to address this problem. CPAN is full of object/relational and relational/object mapping modules. Hell, I've given a lot of thought to writing one myself. But this adds an extra layer of complexity to systems that may well already be complex, and is no friend to performance. Bricolage 2.0 will likely have some kind of mapper built in, but there's one thing I'm sure of: No matter how well designed it may be, it will still suck. Mapping are just an ugly solution, and should be, in my opinion, totally unnecessary.

So why are we all still using RDBMSs? I mean, I know that some of them have object-oriented features (Oracle, PostgreSQL), but they have their weaknesses. In PostgreSQL, for example, if table A has a primary key index, and table B inherits from that table, a query against table B can't use the primary key index in table A. It has to do a table scan, instead! And how many people are really taking advantage of Oracle's OO features, anyway? Not many, I would guess.

Why not push for something better? Why not start working on or with systems that are designed to perform and interact well with well-designed object systems? Where are the ANSI OODBMS standards, and who's using them? What's next in this space, and will the Oracle marketing department ever let it see the light of day?

As for me, I've got on my long list of To Dos to check out Caché at some point. A "post-relational database" is exactly what I'd like to do, and Caché, if InterSystems' hype is to be believed, sounds very promising. Sure it's a commercial system, but there's a Perl interface, and I'd love to see if InterSystems really is revolutionizing databases.

One can only hope.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2003.05.05 21:55 (#19820) Journal
    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.
    The problem isn't with relational databases. It's trying to shove square pegs into a box with round holes.

    Relational databases are great if you're dealing with a small number of composable datatypes (e.g. columns and tables). But they're poor at dealing with highly structured and intricate datatypes (objects). The object/relational barrier is a well-known impedence mismatch. It's reminiscent of the difference in philosophies between Perl and Java -- do you start with a small number of powerful and interoperable types (scalars, lists, hashes and references), or do you start with a a big object hierarchy?

    The crux of the matter is that RDBMSes cover a well-defined area of the spectrum that covers a surprisingly large set of problem domains with nothing more than set theory. Object databases don't have a simple foundation, nor are they easily described with a well-understood set of theories. That's why after 10+ years, there's no dominant object database paradigm, and the best efforts to date have been to subvert relational databases into object stores.

    And, yes, that sucks pretty royally.

    • InfoWorld columnist John Udell talks a bit about the impedence mismatch in a recent colunn []. He mostly ends up talking about Java, though, and simple object serialization, but still, it's good to see a bit of coverage of this issue.


  • Not quite ... (Score:4, Interesting)

    by autarch (914) on 2003.05.05 22:52 (#19821) Homepage Journal
    I use relational databases in my work every day.

    No you don't, actually. You use SQL DBMSs every day. SQL is more or less (mostly less) based on relational theory, but it throws out a lot of the good parts (like mandatory keys, user-defined data types, no distinction between views and base tables) and adds a lot of useless crap (allowing duplicate, Postgres' godawful table "inheritance", ordering depencies (column order)).

    A real relational database would be much more powerful than anything on the market, although making one that is both truly relational and as easy to use as today's SQL DBMSs would be hard, but not at all impossible.

    I strongly suggest checking out Fabian Pascal's Database Debunkings [] site, as well as his book Practical Issues in Database Management. Also make sure to read Chris Date and Hugh Darwen's Third Manifesto.

    Then you'll really hate SQL DBMSs even more than you do now! I know I sure do. I've been toying with the idea of trying to write a truly relational database in Perl for a while now. Alzabo [] is about 2-3% of what I'd need, so I figure I've got a head start ;)