"I've never liked the approach of multiple applications tightly coupled through a common database - you can't get bigger breach of encapsulation than that."
So true. We have some apps here that people didn't make good interfaces for, so when we needed to integrate with the data some folks decided to get at the data directly. Now we're committed to the current schema (and database).
Everything else about this article kind of rubs me the wrong way though -- all the talk about these "non-relational" databases. "Non-relational" databases often don't have relational db features because they can't figure out how to do it given their distributed and/or massive nature. It's certainly not because relational dbs are bad.
Also, the reason why object databases failed is so obvious: there's no precise agreement on what an object is. It's too vague. There's no theory behind "objects", (compare with relational algebra). Do you have multiple inheritence, or not? Are classes first-class (Smalltalk, Python) or not (C++)? Are "objects" class-based or prototype-based?
What we really need (perhaps in addition to less-than-relational databases that are able to handle distributed and large datasets) are more completely relational databases that, among other things, have a rich enough feature set to obviate any need for denormalization and allow us to tell the database more information on what we need it to optimize for us, etc, etc.
Relational DBs are 'bad' because their design has to be fundamentally compromised to be distributed -- removing joins, sharding, denormalizing, etc. -- all of these manual optimizations remove all semblance of 'relational'-ness! Look at Stonebraker's recent publishings -- more restrictive designs are always faster by several orders of magnitude for their specific domains.
There is absolutely a theory behind objects, I urge you to read Luca Cardelli and Martin Abadi's monograph "A Theory of Objects", you'll find all the answers you're looking for there with both rigorous proofs and examples from languages (real and imagined).
OODBs did not fail because of a lack of theory, nearly all of the people writing and using RDBs have a poor grounding in the theory -- see Fabian Pascal's contention that all of the failings of extant RDBs are because they are not relational enough, that SQL is not relational.
OODBs failed because the commercial Smalltalk vendors who had quality products all faded from view, and the term was hijacked by marketing departments pushing bullshit.
The solution I see [Google, eBay, Amazon, etc.] using is to use the DB as raw simplistic storage with strong guarantees, and to push all of the joining and caching up into an application layer. There's no way to "tell the database more information" without using a programming language.
So true. We have some apps here that people didn't make good interfaces for, so when we needed to integrate with the data some folks decided to get at the data directly. Now we're committed to the current schema (and database).
Everything else about this article kind of rubs me the wrong way though -- all the talk about these "non-relational" databases. "Non-relational" databases often don't have relational db features because they can't figure out how to do it given their distributed and/or massive nature. It's certainly not because relational dbs are bad.
Also, the reason why object databases failed is so obvious: there's no precise agreement on what an object is. It's too vague. There's no theory behind "objects", (compare with relational algebra). Do you have multiple inheritence, or not? Are classes first-class (Smalltalk, Python) or not (C++)? Are "objects" class-based or prototype-based?
What we really need (perhaps in addition to less-than-relational databases that are able to handle distributed and large datasets) are more completely relational databases that, among other things, have a rich enough feature set to obviate any need for denormalization and allow us to tell the database more information on what we need it to optimize for us, etc, etc.