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 problem isn't with relational databases. It's trying to shove square pegs into a box with round holes.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.
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.
Re:Object/Relational issues
Theory on 2003-06-03T21:11:11
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.
--David
