Non-Relational Database Use from Perl

To date in my career as a Perl programmer, I have only been exposed to relational databases. However, I am aware that there are other database modalities out there. For example, Lincoln Stein has developed Ace as an interface to the object-oriented database ACEDB, which was primarily for use in human genome research, but, by no means is limited to such tasks. And Joshua Pritikin developed ObjectStore which is used to access the ObjectStore database.

The nice thing about object databases is you can think about getting what you want, as opposed to doing a bunch of table joins to get what you want. The Lincoln Stein TPJ article provides a good example of what I mean. However, at a recent interview (at MSDW), the work involved was taking newsfeeds and storing this in a relational database consisting of more than 100 tables. I asked them if an object-oriented DB would be better and the answer was: "no, we often need to improvise by adding new data and the easiest way to do that is to simply cook up another table and link it into the others via foreign keys." In retrospect, I have to agree, because with object databases, you have the hairy and apparently not well-understood task of schema evolution everytime you decide to add some new and unforseen information to your database.

So,

do you all think that Relational DBs are the way to go and that Object DBs do not offer enough flexibility for unforseen data model evolution?

Can you give some real-world examples of where object-oriented databases are proving useful or even more useful that RDBMSs?

Two post-notes

DBI is called a database independent interface for Perl. However:

Wall Street, which mainly operates on Sybase, prefers Sybase's own non-DBI interface.

I have not seen any DBI::DBD modules for object-oriented databases.

On these grounds, DBI may not be quite as universally used as has been previously claimed.

Comment on Non-Relational Database Use from Perl

Replies are listed 'Best First'.
Re: Non-Relational Database Use from Perl by chromatic (Archbishop) on Nov 29, 2000 at 05:35 UTC
In my experience, I have come across very few problems that cannot be served by a relational database. Sometimes there is massaging involved, mostly when serializing data structures. Of course, that will have to be done with an Object database as well -- I am not aware of any popular disk storage mechanism that does not store information as a stream of bytes. At some point, someone will have to write a layer to serialize data. I find myself using DBI because it's quick, it's easy, and knowing it, I can work with many database backends with ease. In the future, I may need to use another approach, depending on the project. I don't really care if Wall Street claims that wearing ties makes me a better programmer, either. If writing join statements is too painful, perhaps you or someone else will write a tiny bit of syntactic sugar to define a common 'object', using foreign keys or whatever, performing that abstraction for you. I highly recommend abstracting away nasty details of that sort.	[reply]
(Ovid) Re: Non-Relational Database Use from Perl by Ovid (Cardinal) on Nov 28, 2000 at 21:40 UTC
This doesn't address your issue, but it's a side note I thought I would toss in. About a year ago, I worked on a project for a company using a multi-value database. The multi-value industry (Pick, UniVerse, UniData) offers relational databases that violate the first normal form¹ and have built-in mechanisms for dealing with it. Since these databases are not very popular, there was no support for it on CPAN. After posting to a couple of newsgroups, my boss found a guy who had used Perl to write a UniData driver that was perfect for our needs. Of course, he just gave us the driver. Had we gone to the vendor to get one written in C, we could have spent a few thousand dollars (and needless to say, it didn't use DBI). I love Perl :) Cheers, Ovid 1. The first normal form basically states that you shouldn't have repeated data in one field, you should move it to a separate table. A multi-value database allows you to have a table with one person having 17 phone numbers in one field and handles updating and deleting values and their relationships automatically. Such a database is rather nice as linking tables are far less necessary. Unfortunately, I haven't seen any information on how to design these databases. Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]
Re: Non-Relational Database Use from Perl by extremely (Priest) on Nov 29, 2000 at 08:04 UTC
Having used and still being a Sybase fan, I can comment on that part of this. DBD::Sybase was still at version .23 or something until about a week ago. It had few if any of the amenities that the DBI crowd expect or want. The Sybperl module is still the way to go for robust systems. The simple fact in that case is that the author of both, Michael Peppler doesn't have the time to pimp up the DBD version much so work has gotten done on it in spurts. BTW, I still feel that under linux, his .23 version is better than the alternatives for accessing M$SQL 7 DBs. I'm going to be real happy with the 1.0 version once I beat the crud out of the .91 version I grabbed last week. As to the second claim, "I have not seen any DBI::DBD modules for object-oriented databases. " I have to ask, how many NON-DBI modules for OODB have you seen? In this case, it just might be that OODB people don't cater to Perl people and we see little use for them. Saying you've never seen any "easy-to-use throckles" means nothing if you don't give an impression of how many "throckles" you've seen. Putting that algebraicaly, the weight of a person's opinion of a comparitive ratio shall be scaled according to his knowledge of the denominator, not the numerator. One post-note: metaperl wouldn't have put the "Two post-notes" section in... As the the real topic, I think OODBs just sound better to PHBs. In most real world cases I've seen, they would have just slowed the process of getting up and going down to a crawl. Making them fine-grained, flexible, and efficient seems like it is nigh impossible. You can tune a RDBS at the DB, table, and code levels. Half the people in the world wrap the DB in a OOish level at the API anyway and press on from there, maintaining the ability to tinker with the OO stuff away from the outer layers of code without being tied to the vendors OOness. I wrap objects around groups of DBI calls and it is keeping me happy and employed. =) -- $you = new YOU; honk() if $you->love(perl)	[reply]
Re: Non-Relational Database Use from Perl by swiftone (Curate) on Nov 28, 2000 at 21:25 UTC
Two post-notes that appear to have little relevance to your point.... Wall Street, which mainly operates on Sybase, prefers Sybase's own non-DBI interface. I was unaware that Wall Street was one company. Nonetheless, the choice of anyone has little weight on the _I_ aspect of DBI. I'll spare all commentary on the cognitive powers of Sybase users. I have not seen any DBI::DBD modules for object-oriented databases. I no nothing about OO DBs, so I can't say whether DBI can include them easily or not. I'll give you the benefit of the doubt. On these grounds, DBI may not be quite as universally used as has been previously claimed. Would RDBI make you happy? Really, I see no point in this comment. DBI is, arguably, second only to CPAN in Perl's success, and (I'd say) ahead of CGI.pm. Do you have anything useful or constructive to say? Was the rest of your post just an excuse to slide in an attack on DBI? I don't see the point of these comments.	[reply]