

Best alternative to RDBMS and ORMs : Terracotta - edw519
http://www.taranfx.com/blog/?p=736

======
jrockway
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
_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
"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
> 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
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.

------
amix
The Wikiepdia page explains a lot more about what Terracotta is:
<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
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
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
Pray, isn't the 'e' in "English" supposed to be uppercase?

~~~
natemartin
Is there a name for the law that says "anytime you complain about grammar, you
will make a grammar mistake yourself?"

~~~
TomasSedovic
I'm sorry :-)

------
ams6110
"...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.

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

------
lucifer
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.

