Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Robert Martin wrote:
> On 2006-05-30 17:54:53 -0500, "Marshall" <marshall.spight_at_gmail.com> said:
>

>> CMCC wrote:
>>
>>> Marshall wrote:
>>>
>>> I speak in terms of what he *seems to have written*. Somehow I have
>>> to refer to what it is I am talking about! And that is the subject of
>>> this thead.
>>
>> Grrrr. Okay, fine; I'll do the work. In the future if you have a
>> question
>> for me, it will be necessary to ask me the full actual question, and
>> not refer ambiguously to things written elsewhere.
>>
>> [scanning back through the thread ...]
>>
>> Okay, maybe you are asking about this:
>>
>>> No, a DBMS is a bucket of bits with some low level rules to manage
>>> those bits.  An OO application provides the beavior that the customer
>>> wants to see.  We can completely eliminate the DBMS and replace it with
>>> another of an entirely different form (non Relational for example) and
>>> still have all the business behavior we need.
>>> The people who sell databases have sold you, and the industry, a
>>> misconception: that the database is the heart of the system.  This is
>>> flawed.  The heart of the system is the application code.  The database
>>> is a detail to be decided at the last possible moment and kept in a
>>> position so flexible that it can be swapped out for another at a whim.
>>
>> There are many different contexts in which software is developed.
>> I will speak relative to enterprise software, which is where DBMS
>> software is often found. In that context, the above quoted
>> paragraph is pure, unadulterated garbage. It is not simply
>> valueless; it is actively harmful. The writer furthermore
>> demonstrates that he completely lacks any understanding
>> of what the field of data management is, or what it is for,
>> or why it is useful.

If by API you mean SQL, then no, they shouldn't. If by API you mean some low-level interface between your OO language and the DBMS, then it might or might not make sense to wrap one low-level interface in another.

   Should those application designers use
> every little cute ORACLE trick and call?

Should they go out of their way to use features only available on Oracle? No. Should they spend days jumping through hoops to avoid them? No.

   Or shoudl they stick to
> standard SQL as proferred by ODBMS or JDBMS, etc. Should those
> application developers scatter embedded SQL all through their
> application code?

Sure. The real question is: Should they scatter low-level languages like C++ or Java all through their application code?

   Or should they partition that application code into
> areas that know about the DB and areas that don't?

I don't see how that is relevant to any of the idiocy you have posted. One might partition applications any number of ways. Some will be better than others by various measures.

   Should they strive
> to make it possible to swap Oracle for MySql or not?

If you mean to replace MySql with Oracle, that's trivial. If you mean to replace a data management system with a file processor, that's generally rather stupid unless one is using so little data management that the cost of the swap is hardly noticeable in the first place.

   Should they strive
> even to eliminate the relational flavor of the data from the guts of
> their algorithms, or not.

Eliminate relational flavor? That doesn't make any real sense on its face. Do you mean set algebra or predicate logic? In any case, they should strive to eliminate the stink of the lower level languages they find themselves stuck with and try to elevate their code as much as possible by using higher-level abstractions like relations.

Did effective abstraction cease to be a worthy design goal?

>> The reason why you see crap like this is because it is being
>> written by application developers. Application developers are
>> great at writing applications, but once they have success in
>> that one area, they overgeneralize and begin to believe that
>> their techniques are the correct techniques to apply to every
>> software development area. However this represents a
>> multi-decade regression in the field of data management.

I agree. If you were not so ignorant, you wouldn't overgeneralize the way you do.

   However,
> I understand both sides quite wall,

Quite frankly, you are full of shit. As many others, who do understand both sides very well, have already noted, what you post is ignorant, stupid tripe. Your posts are incoherent on their face. One who understands 'both sides' doesn't post the sort of ridiculous nonsense you do.

  having done both and been resonsible
> for both, for damned near 35 years now.

And people actually paid you for it?!? That's sad. I guess you are proof of the adage that some people will get 35 years of experience while others will get one year of experience 35 times.

I also agree that my "pure
> unadulterated garbage" above was spoken from the point of view of an
> application developer.

As an application developer, I note that it is pure unadulterated garbage from my perspective as well.

   The reason for that, of course, is that it was
> in response to database developers overgeneralizing their own point of
> view.

I don't know what you responded to, but the incoherent drivel you wrote could only be written from a position of ignorance and stupidity.

>> Data management in the 1960s lacked any understanding
>> of the issues that the field has today. And if the application
>> programmers have their way, and the existing field of
>> data management is discarded, those same application
>> programmers will face all the same problems that the
>> programmers of the 1960s did, over again. And over
>> the decades, they'll build systems that tackle questions
>> like integrity enforcement, ad hoc queries, transaction
>> management, etc. Slowly, they will reinvent the field.

As an application developer who understands the relational model, I have no problem seeing eye-to-eye with database designers and administrators. You flatter yourself if you think you have anything special to offer that database practitioners don't already understand better than you ever will.

   For, of course, the inverse operation is occurring on the
> other side of the divide. Database application developers are slowly
> learning what software application developers have fought long and hard
> to learn over the last 30 years.

Slowly learning? That's laughable coming from someone as obviously ignorant and stupid as you are. The fact is, after more than 30 years of long hard struggle, the OO folks are nowhere near as advanced as the relational model was the year before you started your career.

   That coupling and cohesion matter, and
> that partitioning, data hiding, and isolation are necesary for large
> applications.

Regardless whether using the algebra or the calculus, the relational model allows one to couple or decouple at will. Views are far more powerful for the dealing with the remainder of the issues you mention than anything the OO crowd have ever dreamt up.

The logical and physical independence of the relational model allow one to largely automate the task of managing the complexity that the above issues attempt to manage.

> Fortunately, there are groups like this one in which the two sides and
> discuss the issues with each other. So long as we can avoid calling
> each other names, we might even be able to learn from each other.

Thus far, you lead me to suspect you have nothing to offer to anyone who understands the relational model, and your claim of 35 years working with it while posting such ridiculous nonsense leads me to suspect you are impervious to learning.

>> And, if they do so, it would be poetic justice if the
>> programmers being born today trash all their work
>> in favor of some new fad.

What you have never seen is a relational abortion. The clay feet of 4gl abortions have always been their 3gl roots. Received on Wed May 31 2006 - 20:12:49 CEST