"Roy Hann" <specially@[EMAIL PROTECTED]
> wrote in message
news:SPGdnTDxOuOeXcLVnZ2dnUVZ8q7inZ2d@[EMAIL PROTECTED]
> "David Cressey" <cressey73@[EMAIL PROTECTED]
> wrote in message
> news:GcO7k.7467$qb7.5691@[EMAIL PROTECTED]
> >
> >> > Get the programmors off their ***** and tell them to learn how to
write
> >> > dynamic SQL.
> >>
> >> Hmm, better watch it here. :-) Both he and I are programmers.
> >> Though I'm not sure where dynamic SQL comes in to play here.
> >
> > I'm not sure how dynamic SQL applies either...
>
> I'd better explain then, since someone else queried it.
>
> When the OTLT is combined with EAV you seem to be able to get away with
> having a single maintenance function. If you abandon OTLT and have
multiple
> lookup tables then EAV is seen to be as stupid as it is, and so that
gets
> abandoned too. At which point it seems you need a distinct maintenance
> function for each lookup table. Dymanic SQL allows you to code a
single
> maintenance function because you can adapt to different numbers of
columns
> and columns of different types.
>
> Obviously this is not an issue with interfaces like ODBC and JDBC, where
you
> already code at a low level similar to dynamic SQL, but it is unfamiliar
to
> Cobol programmers and their kind, who are used to embedded SQL.
>
This is extremely interesting to me. I want to question what you are
saying
and maybe even differ with you, but I don't want to start another one of
those sterile usenet debates. I've read enough of what you write to have
respect for your opinions, and I hope that's mutual. So I hope we can
explore this subject in some detail, and generate more light than heat.
I'm more familiar with embedded SQL as an interface to application code
than
I am with ODBC or JDBC interfaces. (I never programmed in COBOL but I
taught database programming to COBOL programmers). I suspect that low
level
programming carries a cost with it, and that part of that cost is that
programmers continue to "think like programmers", instead of learning to
think in SQL. That could be part of the attraction of OTLT and EAV to
them.
But the embedded SQL that I used was not "dynamic", as I understand the
term. The precompiler processed the embedded SQL, opened a database
whose
metadata was supposed to be the same as the target database, rewrote the
SQL in some lower level language that I didn't need to know, and replaced
the emebedded SQL with calls to these generated lower level routines
before
passing the result to the compiler. We had something we called
"dynamic"
SQL as well. But that involved generating SQL at run time, and letting
an
SQL interpreter parse it. I suspect you are using "dynamic" in a
different
sense than I am, but I'm not sure.
In any event, the interesting thing is, IMO, not so much at what point
the
SQL is parsed and bound, but how automatic the process is of generating
the
SQL needed to reference and maintain a new code table. Back in the day,
new code tables didn't occur often enough to do some heavy automation of
the
process, but the necessary coding was so well understood that the manual
effort was relatively trivial. So the idea of storing all in one table
"to
save programming effort" seemed like a bad joke to me. And the "delay
due
to the cranky DBA" was not the kind of issue in my context that it is in
some of today's programmers.
In all my years of visiting newgroups and other forums, I've never quite
learned why programmers think that database programming is so difficult.
I
think this discussion might help me understand that. Thanks for a
considered reply.
In all my years of discussing
|
