Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates
 207.126.148.87 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4BAD3239.7090800@gmail.com>
References: <4BACC608.4050109@gmail.com>
	 <c3ac3bad1003261121h5545b407k9c68cfbe4b6f6ac1@mail.gmail.com>
	 <4fe4c4f51003261123v99b70f4m3e93fa51fcbdf536@mail.gmail.com>
	 <c3ac3bad1003261256o4e5b2452g8de4a75f8d53040e@mail.gmail.com>
	 <4BAD3239.7090800@gmail.com>
Date: Sun, 28 Mar 2010 19:28:06 +0200
Message-ID: <c3ac3bad1003281028g652d3221i3c2a0cc4f442b725@mail.gmail.com>
Subject: Re: A generic question about JackRabbit
From: Alexander Klimetschek <aklimets@day.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Mar 27, 2010 at 00:16, Rami Ojares <rami.ojares@gmail.com> wrote:
> But Alex said a few radical comments so I just can't refrain myself from
> commenting them a little.
>
>> I think normalization is often thought to be absolutely fundamental
>> for any data schema, because it is a central part of RDBMS and this is
>> basically the only thing that was taught the last 20-30 years (went
>> this route myself). But a major reason for normalization was simply
>> the space constraint, it's not fundamental at all.
>>
>
> Data normalization is concerned with issues of how the relational model
> should be used.
> If you don't have the data in 1st normal form then the relational operators
> and other tools
> that the relational model provides are unable to query the data.

Yes, and all I was saying that because of space constraints, a storage
model around normalization won. I didn't say that normalization is
generally bad, and I didn't question the obvious fact that
normalization is a central concept of an RDBMS.

>> The same story with the ACID constraints... banking accounts are not
>> the only software application nowadays ;-)
>>
>
> Wow, that came out of the bush and hit me right there in the back between my
> shoulder blades ;-)
>
> Basically what you are saying is that when you update data in your storage
> system (that could any data model)
> you don't really care if only part of the data you sent there got updated
> (Atomicity)
> You don't care that if you have set some rules for your data that these
> rules are respected. (Consistency)
> If many threads are accessing the data it does not concern you if they see
> each other's updates
> partially and modify each others data while their operations are underway.
> (Isolation)
> And certainly you don't give a toss about whether your data really stays in
> the storage once you have put it there. (Durability)
>
> The reason why acid properties are related to banking industry is that
> people demand correctness when banks deal with their money.

Yes, I didn't question that, I just noted that banking is a very
special case. And it comes at a cost that most banking applications
are blocked an entire night to be able to safely process transactions.
It's just that banking is the number one sample and teaching schema
for RDBMS, because it's very good at it. However, this affects how
people think about data storage, as if ACID is a given requirement for
everything. It isn't. I think this opens up quite a bit nowadays in
light of the Nosql movement. See the CAP theorem [1].

Most applications don't need all those strict constraints, eg. can
perfectly live with eventual consistency. The real world is not
perfect either.

All I am saying is that it's just necessary to detach from certain
principles in the RDBMS world if you want to see the big picture.
Whatever you chose in the end depends on the needs of your
application. And there are many applications that don't benefit from
the (strict) RDBMS model, rather they loose flexibility, performance,
etc.

[1] http://en.wikipedia.org/wiki/CAP_theorem

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com