Re: The IDS, the EDS and the DBMS
Date: Mon, 06 Sep 2004 23:21:43 +0200
Message-ID: <413cd4f4$0$42417$e4fe514c_at_news.xs4all.nl>
Alfredo Novoa wrote:
> mAsterdam wrote:
>>>>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.
Very clear, thank you.
> The result is that you don't work with an SQL-DBMS anymore.
For an EDS, no real datasharing required, an SQL-DBMS might not be necessary.
>>>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?
Sorry. ISTM = It seems to me.
> ... We have that vocabulary. It is in the classic computer science books.
Classic as in pre-xxx? xxx being relational, object?
>>>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.
True :-( but side-track, no?
>>The performance hit stays, evidently.
>
> But in most cases the performance hit is very negative.
>
> See this:
>
> http://martinfowler.com/articles/dblogic.html
ISTM (heh) that Martin Fowler knows his business.
He knows his audience (OO students)
and how to not lose his audience in
giving advice: by prodding along at first.
>>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.
Ok, I'll hold you to this (as soon as I feel up to the challenge of being specific enough).
>>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.
Accidents will happen. When many cars are driven by untrained chauffeurs it is a certainty. I don't know how or when the need for drivers licenses emerged - hmmmm digressing again. Maybe we can analyse the clashes.
> By the way the capitalization is not mine, in
> English the proper nouns are capitalized.
It looked german (German?) and somewhat
putting it on a pedestal to me.
However, english is't native to me,
so I'll leave that to those who know better.
Received on Mon Sep 06 2004 - 23:21:43 CEST