Avoiding the Functional-Relational Bridge
When I want to develop an application, I choose the best language for the job. But when I want to develop a web application, no matter what language I choose, I feel restricted by the current selection of database technology.
Standard industry practice is to use a database as the storage mechanism of your web application. That's to take advantage of ACID properties as well as to be able to scale-up well.
But I always have problems with it. The types rarely correspond to the types I have available in my programming language. And a row in a table does not map well to an object. Let's not even go into how you have to define your row format ahead of time. All in all, the relational databases are so fundamental a piece of your application that they drag down your coding practices to its lowest common denominator. I hate it, and I've searched far and wide for alternatives.
One alternative is AllegroCache. It's a persistent object database that you query using Prolog. Slava Akhmechet did a great job explaining the how and why of AllegroCache. AllegroCache looks great. It's a heavy-duty database, with full transactions, and it lets you store plain-old CLOS objects. That's really nice, since you never have to build a bridge to a table-based database.
I've never used AllegroCache since it's expensive. I try to use open source whenever possible (because it's free). But I haven't found an open-source persistent object database. There are some attempts at open-source equivalents. Elephant and PLOB! come to mind. I think there are licensing issues with PLOB!. I have heard good things about Elephant, but I have never used it myself. I just might try it for my next project!
Subscribe
Comments
don't forget about rucksack
don't forget about rucksack
AllegroCache rocks, but...
I too have struggled with the relational bridge. Before I knew about Object databases (caches), I tried serializing objects into database rows and putting the data I generally searched by into other fields of the row. The problem was that invariably I wanted to query or summarize by data that was in the object - this required deserializing every object and manually writing functionality that was already there in the SQL database.
When I discovered AllegroCache I was elated. It makes STORING Lisp objects pretty much transparent. Getting those objects back out of the database is another story. Although there is an advanced query interface which uses Prolog, the primary, most efficient methods of querying AllegroCache rely on building your own indexes. As I was programming I found myself really struggling to do things which were totally simple with SQL. For example, try sorting. Trivial in SQL, not so trivial in AllegroCache; try sorting by one property and THEN by another property.
The truth is that AllegroCache makes possible some things that are pretty impossible in traditional relational databases. I had just hoped that I would have ALL of the features I'd gotten used to with relational databases (with the same easy level of accessibility) AND THEN all the other great features of an object database.
I found that in order to really effectively use AllegroCache, one should have a firm understanding of data structures. In part of an article on another OODBMS I read this quote:
"many of the most compelling applications are a result of someone building a custom data structure to store and index the information in a unique way." I realized then that AllegroCache is just another tool in the arsenal to be used when its abilities fit the task. If I have a very complex data structure which doesn't fit well into a relational model or which, when normalized, is REALLY SLOW, I should use AllegroCache. When the data with which I'm working fits well into the relational model (which most of the time it does), I should stick with a relational database. I have considered a hybrid approach using a relational database to essentially serve as the index into an object database - but that is starting to feel remarkably similar to my first serialized object attempt... full circle...
I think that semantic data is a perfect example: the concept of triples simply doesn't fit in a relational model nearly as gracefully as it can fit in an object model (in my opinion). The performance of Franz's AllegroGraph (which bears many similarities to, and shares some code with AllegroCache) compared to any other semantic database founded in a relational database shows the importance of a data structure that fits the thing being modeled. ( http://agraph.franz.com/allegrograph/ - see performance link )
(article containing above quote: http://dlweinreb.wordpress.com/2007/12/31/object-oriented-database-manag... )
I'm VERY interested in anyone's input. I too would like to forget about object-relational mapping or thinking "square" (relational) when I'd rather think "round" (objects).
-Kiyu
Post new comment