RDBMS as a pattern
Recently there has been a discussion on the squeak-dev mailing list about when an RDBMS is appropriate. The discussion started with a comment by JJ, who said that they were very appropriate for the right problem. Howard Sterns naturally asked what problems were the right problems. This set off a flurry of messages, only a few of which I am noting.
Many people on the list liked OODBMSs, but Todd Blanchard (in his blog) argued against them. James Foster said that Gemstone did not have these problems. Nobody noted that Gemstone demoed at the first OOPSLA in 1986 and is a respectable sized company, while the OODBMSs that people criticize are either fairly new or with very small companies or both. Making a DBMS fast, reliable, etc. is hard. When you reuse a software component you are making your system depend on it and if your system is mission-critical then you do not want it to depend on software that is not reliable or is not well supported. One of the main advantages of RDBMSs is that they are old, boring technology that is produced by companies that have been selling them for a long time and that knows how to support them. And make money off them!
Gemstone is a great alternative if you are using Smalltalk. It is expensive, but not compared to large Oracle systems. I know they have some bridges so that non-Smalltalk programs can use it, but its whole model is so Smalltalk-oriented that I can't see why any company would use it unless the most critical parts of their software were written in Smalltalk. And as far as I know, none of the other OODBMs are as good as it is.
Goran pointed out that systems based on RDBMSs tend to grow unpredictably and become big balls of mud. But most systems tend to grow unpredictably and become big balls of mud! The usual argument for RDBMSs is that by making a good data model, you can have all sorts of applications reuse the data, and that the data will live much longer than the applications. As Goran pointed out, this would be nice if it happened, but in practice, the data is often highly coupled to the application.
If you don't have good architects, big systems will end up as big balls of mud. A lot of companies live with it, but there are certainly big payoffs if you can avoid it. The main problem is that there aren't enough good architects to go around. One of the advantage of a RDBMS is that it is fairly easy to understand so below average programmers can still get systems running. Below average programmers will not build the best architectures, though. So, the fact that RDBMs lead to big balls of mud is actually a sign of an advantage. You can use a RDBMS when you have good architects and when you don't. You'll end up with completely different systems, but that is because of the quality of your architects, not because of the technology you use.
I posted a response, too. I said that my favorite persistence pattern was the one of Prevayler, but that an experienced architect should know about XML, OODBMSs, and RDBMSs, because each had its place. In fact, there are at least two ways of using an RDBMS from an OO language. One is to use a object-relational mapping system, but another is to use SQL directly and to have the domain model in tables rather than the objects. I prefer a slight generalization for Smalltalk; have a library of Query objects that let you model the queries as objects rather than as strings. This works well when your applications are basically analyzing existing RDBMs and not changing them.
One of the advantages of thinking of RDBMSs as a pattern is that it makes you stop asking "is it a good idea" and start asking "what are its advantages and disadvantages" and "when should we use it instead of its alternatives". For example, if speed is your number one criterion then you probably shouldn't use a RDBMS. That is why RDBMSs are big in enterprise applications and not in supercomputer applications. An enterprise app must be fast enough, but if you can process all your transactions every day and can give responses to people in a second or less, your app is probably fast enough. Enterprise developers often complain about performance, but compared to real-time developers or supercomputer programmers, performance is not very important to them, and the fact that RDBMSs are so popular among them is proof of that. On those occasions where performance IS important, get a new database.
One of the advantages of an RDBMS is that it tolerates bad data pretty well. It is usually not hard to look at your data and see what is wrong. XML is like this, too. OO databases tend not be like this, though Gemstone is an exception because you can use Smalltalk tools to inspect and modify the data.
I started this a week ago and have more to say. I will post it and hope I have time to add to it soon.
