jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rami Ojares <rami.oja...@gmail.com>
Subject Re: A generic question about JackRabbit
Date Fri, 26 Mar 2010 15:07:17 GMT
On 26.3.2010 16:46, Joseph Ottinger wrote:
> It was E.F.Codd, for one thing, and not Ted. :)

Ted was his nickname.
I was trying to be casual :-)
(But I see you realized this while I was writing this email)

> But... relational models work very well for *reporting* but not so much for
> other things. They're kinda slow, for example. Hierarchical and set-related
> models (document-based, ODBMS, and CODASYL dbs, respectively) are much, much
> faster for some operations, and slower for others.

Yes the speed issue.
It is true that if your data is structured hierarchically and you access 
it in your application then you can create
the fastest application by storing it in the fashion that is good for 
the first application.
It just so happens that other applications come along that want to use 
the same data also (to avoid redundancy).
And for them the hierarchical model might prove to be a nightmare.

The key idea of relational model is that it is a generic way to model 
any kind of data.
New data structures can be derived from the relations the data has.
Ad hoc data models do not have this property.
But of course are completely valid if only one application uses them.

> Relational models excel in reporting and warehousing. The rest... meh,
> they're kinda slow on updates and set relationships. We're just so used to
> the lack of speed that we think it's the norm.

The lack of speed comes out of users wish to have constraints on the 
data model.
If you allow any kind of data into your relations then I don't see why 
relational model would be slow.
The only reason would be bad implementations.

Further relational model is a MODEL not implementation.
So implementation can be anything as long as it produces the relational 

> However, if you're doing a lot of updates or your set modifications are
> common, you'll typically find the other models faster, and - depending on
> your taste - easier.

I would like Thomas Mueller (developer of H2) to comment on this.
Is the speed somehow related to the relational model?
As far as I understand the speed suffers because of ACID requirements, 
not so much because of the relational model.
And the poor usability comes from standardization (SQL).

Standards are good because of compatibility but they rarely if ever 
produce the optimal user experience.

> Certainly transaction processing is easier with nonrelational.


> That's not to say that relational databases are *bad* -- they're just very
> good at structured data, used for reporting, which is what they were used
> for most often. Now they're seen as part of the background noise of data
> storage, so everyone converts their problem into something the relational
> database can use - as opposed to finding the solution that fits the problem
> well.

I think people use the relational model because projects who produce 
data that is never reused in other applications are rare.
Also I don't see non-relational models as "bad" :-)

> We've decided to let our tools dictate our solutions, instead of picking our
> solutions to fit our problems.

Tools no policy.
Well I am all for this one.

- rami

View raw message