Re: The IDS, the EDS and the DBMS

mAsterdam <mAsterdam_at_vrijdag.org> wrote in message news:<413ae81a$0$10528$e4fe514c_at_news.xs4all.nl>...

> >>Why are these object-relational mapping projects bogus?
> >>Is it because bridging the impedance mismatch is not a
> >>worthwhile quest, is it because it it impossible or
> >>just because none of these projects has done a good
> >>job at it yet?
> >
> > It is because they eliminate the disease killing the patient.
>
> The patient being?
> The disease being?
> Let's try to properly pin-point the problems and the stuff
> we'ld like to save.

The patient is the SQL-DBMS, the disease the object-relational mismatch.

The result is that you don't work with an SQL-DBMS anymore.

> > The solution is to include relation variables and the relational
> > algebra/calculus in the application languages and not to hide the
> > declarative set oriented DBMS behind a procedural record oriented
> > layer.
>
> That would indeed be nice to have.
> ISTM that is one way of trying to do object-relational mapping.

What ISTM is?

> Maybe tha best -

And the way of the object-relational projects in SourceForge is probably the worst.

> but we can only find out after we have a
> common vocabulary to discuss and evaluate the alternatives.

We have that vocabulary. It is in the classic computer science books.

> > The hide the power of The Relational Model forcing you to manage the
> > data procedurally in the application.
>
> I'll try translating this into a less relational *versus* object
> version:
> One thing the projects should not try to hide in hiding the
> complexity is the ease of operating at set-level.

And using the set algebra/calculus.

> Another no-hide thing is the power of declarative languages.
> Am I understanding you correctly (for now dodging the implications)?

Yes.

> >>Trade offs are to be expected.
> >
> > And they are often impressive. The code size
> > grows in orders of magnitude.
>
> Yes. One nuance: Code is used more often than it is written,
> so in widely used systems a part of this cost dissappears.

No, the cost surplus never dissapears, but it is true that it may be little in percentage.

For instance if you charge 8 million € for something that could be done for 100.000€ but you employ 2 million €, you still win a lot.

I know cases like this. The low productivity helps a lot to hide the fraud.

> The performance hit stays, evidently.

But in most cases the performance hit is very negative.

See this:

http://martinfowler.com/articles/dblogic.html

> While this does express your attitude,
> it does not explain why (or where) the
> relational interface would be
> of just the right complexity.

Because it is all in the books all we know, and I have no time nor the intention to type the whole books here :)

But of course we can discuss any specifical point you want.

> I think data sharing is not and should not be
> the privilege of people with a sound knowledge of
> "The Relational Model" (capitalization yours).

I think that database system development should be the privilege of people with at least an elementary knowledge on the basics of the data management field.

By the way the capitalization is not mine, in English the proper nouns are capitalized.

Regards Received on Mon Sep 06 2004 - 12:19:12 CEST