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:
> >
> > 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.
>
> [...]
> Are you saying that it is "pure unadulterated garbage" that application
> developers should isolate their application code from the the whims of
> the API designers at Oracle? Should those application designers use
> every little cute ORACLE trick and call? 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? Or should they partition that application code into
> areas that know about the DB and areas that don't? Should they strive
> to make it possible to swap Oracle for MySql or not? Should they
> strive even to eliminate the relational flavor of the data from the
> guts of their algorithms, or not.

Seven consecutive leading questions and my parser runs out of memory. Uh, let's see: yes, as appropriate, ideally (assuming you mean JDBC; I don't know what JDBMS is), no-of-course- not-I-never-suggested-otherwise, yes, no, probably not.

(Perhaps we could come up with a better format for dialog.)

(Why are you so stuck on Oracle, by the way? Are you thinking I'm an Oracle salesman?)

> > 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 with some of this. Much of this debate comes from one side not
> understanding the position of the other, and overgeneralizing.
> However, I understand both sides quite wall, having done both and been
> resonsible for both, for damned near 35 years now.

Your CV is excellent. Mine is too.

> I also agree that
> my "pure unadulterated garbage" above was spoken from the point of view
> of an application developer. The reason for that, of course, is that
> it was in response to database developers overgeneralizing their own
> point of view.

My point of view is also that of an application developer, because that is what the vast majority of my career has been. However I have been quite impressed with the achievements of the field of data management, and have worked hard to educate myself in it.

I have not noticed the same level of attempting to destroy and belittle the achivements of the other side coming from the data management camp as I have from the application developer camp. (Although I will grant you it occurs.) I think it may have to do with the fact that the dbms people have always had to work with application developers, while many of the application developers have only recently had to start working with the dbms camp.

> > 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.
>
> It is actually not a bad thing that one side is forced to reinvent the
> other, Indeed that may be the only way for the two sides to see
> eye-to-eye.

Hmmm, well, I see your point but it is a bit panglossian for my tastes. I would like to think the two sides could come together and learn from each other. I have tried to embody that myself, as an application programmer studying the ways of the RM at the Jedi Academy. I would like to believe there is a more mature discipline waiting to be born, that encompasses the achievments of each, and unifies them. They are not mutually antagonistic; only the actual people are. :-)

> 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. That coupling and cohesion matter,
> and that partitioning, data hiding, and isolation are necesary for
> large applications.
>
> 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.

OT: I am not sure a lack of namecalling is a prerequisite. I actually begin to suspect that namecalling, on usenet at least, is inevitable.  

Marshall Received on Wed May 31 2006 - 19:26:23 CEST