Help
Comparing current revision with historical revision 0.
Document History: In defence of the RDBMS
Current revision:
1
Parent:
Gavin
Created On:
24. May 2007, 01:15 (gavin)
Last Modified On:
30. Dec 2007, 00:01 (gavin)
Historical revisions:
0 30. Aug 2007, 08:41 (gavin) ShowDiff

From line 4 changed to line 4:
++ Benefit \#1: Eliminate the complexity of object\/relational mapping!
++ Benefit \#1: Eliminate the complexity of object/relational mapping!
From line 16 changed to line 16:
Suppose that the IT industry, in a temporary attack of collective self-delusion, ever did decide to rip out all those massive rust-encrusted relational databases, and replace them with shiny new object databases. In a further ten years, we'd be hearing all about the "impedence mismatch" problem of object\/object mapping.
Suppose that the IT industry, in a temporary attack of collective self-delusion, ever did decide to rip out all those massive rust-encrusted relational databases, and replace them with shiny new object databases. In a further ten years, we'd be hearing all about the "impedence mismatch" problem of object/object mapping.
From line 20 changed to line 20:
One of the cool things about object database technology (and the briefly fashionable object\/relational database technology from the 1980's) is that the database can have a much richer type system compared to the simple primitive types available in traditional SQL databases. Isn't it nice to just be able to have an attribute of type Duration (from the Joda Time API), instead of having to map it back to relational database types?
One of the cool things about object database technology (and the briefly fashionable object/relational database technology from the 1980's) is that the database can have a much richer type system compared to the simple primitive types available in traditional SQL databases. Isn't it nice to just be able to have an attribute of type Duration (from the Joda Time API), instead of having to map it back to relational database types?
From line 44 changed to line 44:
Invariably, these sorts of solutions are benchmarked running in the same process as the application. In many cases, that's the only way they can run. But in a real enterprise environment, you only sometimes get the option of running the database on the same box as the application servers. When you do, it would certainly be nice to run in-process, but this is not a conceptual problem of relational technology, the problem is that existing, mature RDBMS systems happen to not be written in Java (see Benefit #3).
Invariably, these sorts of solutions are benchmarked running in the same process as the application. In many cases, that's the only way they can run. But in a real enterprise environment, you only sometimes get the option of running the database on the same box as the application servers. When you do, it would certainly be nice to run in-process, but this is not a conceptual problem of relational technology, the problem is that existing, mature RDBMS systems happen to not be written in Java (see Benefit \#3).
From line 68 changed to line 68:
It is often claimed that object databases help eliminate the n+1 requests problem when fetching data from a remote server. However, there is no a priori reason why an object database should be any faster than an ORM solution for this. Modern ORM solutions offer very efficient association fetching strategies and options for tuning fetching strategies. However, I will concede that there is a particular case where current relational technology is inferior: fetching of arbitrarily deep graphs of data in a hierarchical relationship. There is no reason why standard SQL could not provide features for optimizing this case, indeed, certain vendors already have proprietary extensions for this. And there is no good technical reason why ORM solutions could not take advantage of these extensions. However, as far as I am aware, no current product does so.
It is often claimed that object databases help eliminate the n\+1 requests problem when fetching data from a remote server. However, there is no a priori reason why an object database should be any faster than an ORM solution for this. Modern ORM solutions offer very efficient association fetching strategies and options for tuning fetching strategies. However, I will concede that there is a particular case where current relational technology is inferior: fetching of arbitrarily deep graphs of data in a hierarchical relationship. There is no reason why standard SQL could not provide features for optimizing this case, indeed, certain vendors already have proprietary extensions for this. And there is no good technical reason why ORM solutions could not take advantage of these extensions. However, as far as I am aware, no current product does so.
From line 80 changed to line 80:
Finally, some people are still not using ORM, or are using immature ORM solutions. This is especially a problem in the Ruby community, where the lack of a decent persistence solution is partially obscured by the fact that Rubyists tend to function in evangelistic\/defensive mode continuously (compared to the Java tradition of intense self-criticism) and by the fact that the kind of applications that people are usually allowed to build in Ruby don't have the combination of complex legacy data models, complex business logic and large deployment scale that characterizes interesting projects in the Java world. But my expectation is that at some stage someone in the Ruby world will do enough self-examination to realize that they need to port Hibernate to Ruby.
Finally, some people are still not using ORM, or are using immature ORM solutions. This is especially a problem in the Ruby community, where the lack of a decent persistence solution is partially obscured by the fact that Rubyists tend to function in evangelistic/defensive mode continuously (compared to the Java tradition of intense self-criticism) and by the fact that the kind of applications that people are usually allowed to build in Ruby don't have the combination of complex legacy data models, complex business logic and large deployment scale that characterizes interesting projects in the Java world. But my expectation is that at some stage someone in the Ruby world will do enough self-examination to realize that they need to port Hibernate to Ruby.