5 ms·

Best alternative to RDBMS and ORMs : Terracotta

14 points by edw519 17y ago

jrockway 17y ago
This is a really poorly written article. (You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions".) But, object databases are a great idea for many applications. With KiokuDB (a Perl object database), you can even serialize closures. That means, for example, if you have a stateful web app, and one server crashes between requests, any other server can handle the request just fine; without any state loss, and without rewriting your closure-based app in terms of classes. (Same expressive power, different syntax.)
- CodeMage 17y ago
  You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions". What's so retarded about Joel's concept of "leaky" abstractions?
  - jrockway 17y ago
    "TCP is a leaky abstraction because it can't recover from cut network cables." OK, technically true, but the issue is the scope of the abstraction, not that it is leaky. You could say that C is a leaky abstraction because C programs don't work if you shut off the underlying CPU. Technically true. Completely irrelevant. C can't control your power button. TCP can't control crazy people with scissors. Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. Finally, I don't think that ORMs are leaky. With enough effort, all object graphs can map to a relational model. Most people don't want to exert that much effort, but that doesn't mean object/relational mapping is a leaky abstraction. It doesn't really mean much of anything. (I agree that polymorphism and graph structures are hard to model, and that's why I generally use object databases. But that is mostly irrelevant.)
    - arohner 17y ago
      > Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. But that's exactly Joel's point. inside the scope of the abstraction, the following properties are true. The whole point is that outside the abstraction stuff breaks, and the kicker is that in many cases, the only practical way to know what is inside the abstraction and what is outside the abstraction is to know the details about the underlying abstraction, exactly what it was supposed to help with! Yes, cutting the network cable is a poor example, but there are many good ones. With C, you can do stupid bit manipulation in ways that will be non-portable across architectures. With ORMs, an easy example is the N+1 select problem. ORMs are typically very leaky, in the sense that to write good quality code, you have to know the details about how your ORM works, and they usually aren't a 100% replacement for knowing SQL. The more you have to know about how the level below you works, the more leaky the abstraction. I think Joel's could have made the point clearer if he had distinguished between how much typing the abstraction saves you, and how much knowledge it absolves you from knowing.
      - jrockway 17y ago
        My experience is different. (I mostly use DBIx::Class.) I am not good at remembering SQL's syntactic quirks, which means I can't sit down and write a query for exactly what I want. But with DBIx::Class, I can walk my objects to get the data I want, and it "compiles down" to one database query. So that's not leaky -- I don't know SQL, I do know OO, and DBIx::Class lets me use my knowledge of one to extract data with the other.
- natemartin 17y ago
  Do you know of a good comparison of / introduction to the various object databases? A quick google search shows a wiki page that has a table listing various features, but I'd be interested in a discussion of the pros/cons of the various options.
Titanous 17y ago
http://jonasboner.com/2007/02/05/clustering-jruby-with-open-terracotta.html http://jonasboner.com/2007/02/05/clustering-jruby-with-open-... gives some info on using Terracotta with JRuby.
amix 17y ago
The Wikiepdia page explains a lot more about what Terracotta is: http://en.wikipedia.org/wiki/Terracotta_Cluster http://en.wikipedia.org/wiki/Terracotta_Cluster - and no, it's not a replacement for a RDBMS :-/ Flagged the article for really crappy content.
- tptacek 17y ago
  Not a good use of flagging. It's not off-topic, it's not spam, and there are already valuable comments here that people took the time to write.
natemartin 17y ago
The author, of this piece, likes using, lots and lots, of commas. I wish more people who put content on the web would spend a little more time understanding english grammar, or at least would find someone to read over a posting before submitting it. This topic is really interesting to me, but the horrible writing is making it very difficult to get all the way through. Ah, now I understand why: "We are coming to the close of 2010." (from the article) He must be translating from some sort of future-language!
- TomasSedovic 17y ago
  Pray, isn't the 'e' in "English" supposed to be uppercase?
  - natemartin 17y ago
    Is there a name for the law that says "anytime you complain about grammar, you will make a grammar mistake yourself?"
    - mahmud 17y ago
      Martin's Law.
    - TomasSedovic 17y ago
      I'm sorry :-)
lucifer 17y ago
There is definitely merit to the notion of using persistent memory to address state management. But neither this (nor "noSQL") in any way addresses the other fundamental utility of a database: querying for data. The need for a (form of) structured querying language (such as SQL) remains regardless of how state is managed. If you are not convinced, simply pretend that your heap is in fact a persistent store (and don't worry about process life cycle) and think through the problem of writing code to extract sub-sets of your object graphs. By the time you are finished with your enhanced collection/graph interface you have reinvented a form of query api. Its not just about state.
ams6110 17y ago
"...what I would even need a database for. "The only reason I can see is, to make data available for data-mining and (so called) BI, Business Intelligence, packages (or warehousing, cubes (as per MS))." So, basically everything businesses want to do with data after the initial entry into the app.

14 points by edw519 17y ago

This is a really poorly written article. (You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions".) But, object databases are a great idea for many applications. With KiokuDB (a Perl object database), you can even serialize closures. That means, for example, if you have a stateful web app, and one server crashes between requests, any other server can handle the request just fine; without any state loss, and without rewriting your closure-based app in terms of classes. (Same expressive power, different syntax.)

CodeMage 17y ago
You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions". What's so retarded about Joel's concept of "leaky" abstractions?
- jrockway 17y ago
  "TCP is a leaky abstraction because it can't recover from cut network cables." OK, technically true, but the issue is the scope of the abstraction, not that it is leaky. You could say that C is a leaky abstraction because C programs don't work if you shut off the underlying CPU. Technically true. Completely irrelevant. C can't control your power button. TCP can't control crazy people with scissors. Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. Finally, I don't think that ORMs are leaky. With enough effort, all object graphs can map to a relational model. Most people don't want to exert that much effort, but that doesn't mean object/relational mapping is a leaky abstraction. It doesn't really mean much of anything. (I agree that polymorphism and graph structures are hard to model, and that's why I generally use object databases. But that is mostly irrelevant.)
  - arohner 17y ago
    > Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. But that's exactly Joel's point. inside the scope of the abstraction, the following properties are true. The whole point is that outside the abstraction stuff breaks, and the kicker is that in many cases, the only practical way to know what is inside the abstraction and what is outside the abstraction is to know the details about the underlying abstraction, exactly what it was supposed to help with! Yes, cutting the network cable is a poor example, but there are many good ones. With C, you can do stupid bit manipulation in ways that will be non-portable across architectures. With ORMs, an easy example is the N+1 select problem. ORMs are typically very leaky, in the sense that to write good quality code, you have to know the details about how your ORM works, and they usually aren't a 100% replacement for knowing SQL. The more you have to know about how the level below you works, the more leaky the abstraction. I think Joel's could have made the point clearer if he had distinguished between how much typing the abstraction saves you, and how much knowledge it absolves you from knowing.
    - jrockway 17y ago
      My experience is different. (I mostly use DBIx::Class.) I am not good at remembering SQL's syntactic quirks, which means I can't sit down and write a query for exactly what I want. But with DBIx::Class, I can walk my objects to get the data I want, and it "compiles down" to one database query. So that's not leaky -- I don't know SQL, I do know OO, and DBIx::Class lets me use my knowledge of one to extract data with the other.
natemartin 17y ago
Do you know of a good comparison of / introduction to the various object databases? A quick google search shows a wiki page that has a table listing various features, but I'd be interested in a discussion of the pros/cons of the various options.

Titanous 17y ago

http://jonasboner.com/2007/02/05/clustering-jruby-with-open-terracotta.html http://jonasboner.com/2007/02/05/clustering-jruby-with-open-... gives some info on using Terracotta with JRuby.

amix 17y ago

The Wikiepdia page explains a lot more about what Terracotta is: http://en.wikipedia.org/wiki/Terracotta_Cluster http://en.wikipedia.org/wiki/Terracotta_Cluster - and no, it's not a replacement for a RDBMS :-/ Flagged the article for really crappy content.

tptacek 17y ago
Not a good use of flagging. It's not off-topic, it's not spam, and there are already valuable comments here that people took the time to write.

natemartin 17y ago

The author, of this piece, likes using, lots and lots, of commas. I wish more people who put content on the web would spend a little more time understanding english grammar, or at least would find someone to read over a posting before submitting it. This topic is really interesting to me, but the horrible writing is making it very difficult to get all the way through. Ah, now I understand why: "We are coming to the close of 2010." (from the article) He must be translating from some sort of future-language!

TomasSedovic 17y ago
Pray, isn't the 'e' in "English" supposed to be uppercase?
- natemartin 17y ago
  Is there a name for the law that says "anytime you complain about grammar, you will make a grammar mistake yourself?"
  - mahmud 17y ago
    Martin's Law.
  - TomasSedovic 17y ago
    I'm sorry :-)

lucifer 17y ago

There is definitely merit to the notion of using persistent memory to address state management. But neither this (nor "noSQL") in any way addresses the other fundamental utility of a database: querying for data. The need for a (form of) structured querying language (such as SQL) remains regardless of how state is managed. If you are not convinced, simply pretend that your heap is in fact a persistent store (and don't worry about process life cycle) and think through the problem of writing code to extract sub-sets of your object graphs. By the time you are finished with your enhanced collection/graph interface you have reinvented a form of query api. Its not just about state.

ams6110 17y ago

"...what I would even need a database for. "The only reason I can see is, to make data available for data-mining and (so called) BI, Business Intelligence, packages (or warehousing, cubes (as per MS))." So, basically everything businesses want to do with data after the initial entry into the app.