This is the correct answer. And the same answer applies to all systems: why most of the mass of our solar system orbits near the ecliptic; why Saturn's rings are flat; why galaxies are flat; why most moons orbit in the same direction and plane as their planet's equator; etc. That which has not yet "canceled out by collision" remains spherically distributed, i.e., the Oort cloud on the outer reaches of our solar system. And, of course, there were local maxima and minima in the original distribution of angular momentum, which could explain, for example, retrograde orbits and why Uranus and its largest moon Triton rotate and revolve in a different plane from most of the rest of the solar system.

And yet there are still many OODBMSs and a growing number of other no-SQL DBMSs and a large number of applications that use them to good effect. You also seem to be forgetting about government/defense/intelligence customers. They're about solving problems, not driving revenue. Businesses, too, if they want to survive and grow, need to solve problems better than their competitors, which means they need to use the best and/or simplest tools for the job, which aren't always relational. Just because something has market share doesn't mean it's the best. (How did Windows get to be the dominant OS?) My opinions expressed here are based on my experience and research. I am happy to pit my credibility against yours.

You should keep your dogma on a leash.

How does Agile contribute to bad design? PRINCIPLES BEHIND THE AGILE MANIFESTO #9: Continuous attention to technical excellence and good design enhances agility. It sounds like you and Marc both dislike inheritance. I, on the other hand, have run into many more problems with too little inheritance than with too much. It's a tool that can be used correctly, used incorrectly, or not used at all.

1. I don't want to belabor the obvious, but "OODBMS" != "OO". I said exactly what I meant. No need to assume otherwise. 2) One of the "smaller simpler" applications on which I worked (for 13 years) was a model-based systems engineering tool. It had an ERA schema editor and database editor (allowing customers to capture and establish traceability amongst their requirements, system behavior, components, etc.), supported multiple concurrent projects with different schemata and schema migration, supported inheritance, included a diagram framework (to dynamically generate customizable hierarchy, ERA, physical block, functional flow, and IDEF0 diagrams from the system model), had a scripting language and IDE, had customizable reports and a web portal based on the scripting language, had a graphical discrete event simulator (to execute system behavior), and supported project-, entity-, and attribute-level security. When one person edited the data, other concurrent users could see their diagrams update in real-time, and vice-versa. All this was done in Smalltalk by 3 to 5 developers using the GemStone/S OODBMS and app server. Shall I go on? What, exactly, do you work on? 3) I am not suggesting that a complex system or system of systems has to have all its business logic in one place, but rather that business logic should run closer to the data on which it operates. This is loose coupling on an architectural level. Really, its a foundation of SOA. Failure to observe this tenet IS a design/architecture problem and often DOES result in poor performance. 4) I write real software, and real software has bugs, which sometimes include the violation of validation/integrity rules. I've never seen a system in which RDBMS constraints alone were used to prevent all invalid data conditions. Besides, are you arguing for or against behavior in the DB?

You might want to read more carefully.

And, here, you are attempting to refute a generalization with a contrived counter-example. Don't take other people's analogies, generalizations, etc. and attempt to stretch them beyond their intended purpose. And don't presume to speak for other people.

I'm not either, but your far future was my mid-1990s.

And what you are doing is relating some business managers to business managers as a whole. You inferred a generalization and then attempted to refute it with a more sweeping generalization.

The database was GemStone/S. We were a VAR and licensed and packaged it with the application. We provided tech support for database issues along with application issues. No administration was required after installation. Hot backups were automated, but the customer was responsible for archiving the backup files, if desired.

Perhaps. The utility of OODBMSs may be an order of magnitude less than that of RDBMSs. But the utility of OODBMSs is at least an order of magnitude greater than their current acceptance. (I.e., there are many applications that could and should use them but don't.) And the utility of OODBMSs would be an order of magnitude greater still if there were a little more investment in them (e.g., a standardized query language). The DBMS landscape has not reached equilibrium and is currently shifting away from relational and ACID.

I wonder if you are having the same conversation I am having. I didn't say anything about putting behavior in the database. But that's kind of the point of an OODBMS, isn't it? If you can transparently persist your business objects as they are, then you don't need to worry about the interface between your application tier and your data tier. And there are serious advantages to executing your behavior as close to your data as possible, chief among them being performance. Fewer transformations in the case of RDBMSs. And less chattiness between tiers in the case of both RDBMSs and OODBMSs. There will almost inevitably be a proliferation of paths to the data. The "closer to the metal" your business logic is, the fewer places it will need to be implemented, and the less likely your validation/integrity rules will get inadvertently bypassed.

I didn't write that. What you attributed to me is the point I was attempting to refute.

Alas, I had somewhat the same experience. When we were using GemStone/S, many potential customers asked what database we were using for out back end. They had no need nor intention of querying the data directly, but they wanted warm fuzzies.

Marc Clifton wrote: The real world is a constantly changing environment of data, behavior, and relationships. One of the first things I learned about OO is that it is wonderfully appropriate when modeling extremely well defined and static relationships, and very poor, except in terms of abstractions, of modeling dynamic relationships. I agree about the dynamic nature of the world. I disagree that OO can't model it. I spent a total of 15 years of my career working at two companies on two COTS product suites, one a family of model-based systems engineering tools, the other a family of knowledge management SDKs. In both cases, we used OO in all its glory to implement an entity-relationship-attribute (including attributed relationships) meta-model. Entities, relationship, and attributes were instances. The types/definitions of those entities, relationships, and attributes, were also instances. Entity definitions could even inherit from other entity definitions. Elegant and maintainable. I have also seen designs that suffer from the maladies you describe.

So your argument is that OO is bad because you do it badly? I would take the exact opposite position on just about every point. OODBMSs are far more flexible and RDBMSs. (Usually, you're not required to worry about or maintain the schema.) One of the strengths of OO is its ability to model and use real-world data and behavior. OO is generally more applicable to business objects than UI controls. And inheritance, if done properly, is a wonderful abstraction. In many cases where there is conditional logic--and in most cases where there is a type cast--inheritance would have clarified and simplified the code.

Have you looked at the JDO Spec? In particular, check out the state-transition diagrams and tables culminating on p.67 of the latest version of the spec. It's just about the most beautiful thing I've ever seen. That's what a persistence mechanism should be. For 9 years, I used GemStone/S, a Smalltalk application server and OODBMS. The application on which I was working would not have been possible without it. We could run the same code on the client and the server, and each thread of execution could bounce between them, depending on where the behavior could run most efficiently. Objects cached in the client could be automatically refreshed when changes to their persistent images were committed. It supported indexing and had an OO query syntax. It had a clustering mechanism so that diverse objects that needed to be fetched together would be stored on the same page. And the fetching was configurable, so you could retrieve whatever piece of an object graph you needed in a single trip. For applications that can leverage features like that, an OODBMS will be more performant than a RDBMS. As others have said, applications that are heavy on aggregation, reporting, and doing CRUD operations on "rectangles" of data, should use an RDBMS. The general rule is that an applications affinity for an OODBMS is proportional to the complexity of its object model.

He even invented a new past in the Eden series. Unfortunately, his version of the future that will probably come to pass is not the Stainless Steel Rat, but Make Room, Make Room.

Unfortunately, my QWERTY fingers are plenty fast enough to keep up with my QWERTY brain. How can I get a Dvorak brain?

A failed launch would have no net effect on the radioactivity of the earth. At worst, it would create a dangerous local concentration (like around the Fukushima plant). On the other hand, every successful launch would actually make the earth less radioactive. Besides, precedents already exist. radioisotope thermoelectric generators have been used in spacecraft for 50 years. And there are many nuclear-powered warships that are built with the possibility in mind of their being blown up or sunk.