Ralph Johnson sobre RDB y OODB

Johnson dedica una nota a una discusión iniciada en la lista Squeak-Dev sobre las ventajas y desventajas de las bases de datos relacionadas comparadas con las bases de datos orientadas a objeto, desde el punto de vista de Smalltalk. Toda la discusión es de interés, pero hay al menos dos participantes destacables, aparte de Ralph Johnson: Todd Blanchard, y Göran Krampe.
Qué dice Johnson acerca de cuándo una base de datos relacional es apropiada:

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!

Entre arquitectos basados en una concepción orientada a objetos (se trata de una lista relacionada con Smalltalk), el paradigma de las bases de datos relacionales no ajusta bien:

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.

Con una posición pragmática, Johnson justifica al modelo relacional:

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.
(...) 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.
(...) 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.

Blanchard suma objeciones a las bases de datos orientadas a objeto:

OODBs are seductive. They are easy to get started with. For one thing, you don’t have to do a data model, just your object model. Your code is your model. You make objects, stick them in containers, and forget about them. Sounds great, right?
But as anyone who has lived with an OODBMS for any period of time knows, Object databases are great, until they’re not, and then they truly suck. Here’s why:
1) Concurrency is very poor. (...)
2) Constant re-fetching of data every transaction makes keeping user interface elements up to date very expensive.(...)
3) Schema migration is hard, if not impossible. Your object defines your format.
4) Death by a trillion bug fixes.(...) [y el #6:6) Bugs are forever.]
5) OODBMS providers have limited resources and will only support versions up to one year old.(...)
7) No security.
8) Garbage Collection is not universally available. Orphaned junk is common.
9) No ad hoc query capability. You have to write a new program to view any data at all. You need to write programs to update reference data. You need a program to do anything at all with your data. No fixing problems with a quick line of SQL. Searching for unanticipated patterns is difficult. [Object Oriented Databases]

...Y Göran Krampe recusa cada uno de estos argumentos, apoyándose en su experiencia con Gemstone.
La discusión sigue...