Re: dbdebunk 'Quote of Week' comment

"David Cressey" <david.cressey_at_earthlink.net> wrote
>
> "Frank_Hamersley" <terabite_at_isat.bigpond.com> wrote in message
>
> > > Celko is right in his diatribe, but he lays it on too thick.
> >
> > Perhaps - he made the best point in another post (excuse my
paraphrasing)
> > that the problem is not the use of surrogate keys per se, but more the
use
> > of identity columns for PK's. I guess in the hands of the great
unwashed
> > there is not much distinction between the two acts, and religious
sermons
> > might prove to be the most effective way to try and hold back the tide.
> >
> Look, I'm in favor of education as much as the next man. A significant
part
> of my career was as an instructor for DEC.
>
> And there's no question that about half the databases being built today
> would be better built if the builders knew how to design a database at
least
> halfway decently. I'm not being a devil's advocate here. But religious
> sermons hold back the tide about as well as king Canute's command did.

It might stop some of the newbies from walking out to see how far the tide ebbs, any to have too scramble to safety when it suddenly turns. :-)

I often wonder if the recent arrivals have sufficient grounding in the underlying technologies to understand the implications of design and implementation decisions? Whilst I never wrote any microcode and only built a few ttl (gate) based devices, when combined with the undergrad course and lots of time in the UCC clubroom, I find I have no trouble analysing design implications to identify where problems might arise (or could be neutralised). Today I suspect ppl are more mono-cultural and expect the underlying layers to simply deliver (and in spades too) without any effort required to rationalise any implications.

> Another question is, how many of the programmers are among the great
> unwashed, and why is this the case?

Lots - I feel because most ppl "don't get it" about computers period! This has however has not been an impediment to many attaining gainful employment because the employers get it even less!

> The deeper question, IMO, is whether databases are still being used as a
> tool for integrating data, and making it more widely accessible, or
> whether most of today's databases are private parts of an application,
and
> there is no useful information to be obtained via SQL, knowing only the
> business model and the metadata. By "more widely accessible" I mean
useable
> in more contexts, not just by more people.

My recent experiences suggest there is a trend to use database systems to provide direct access for those so bold as to use it as a means of reassuring RFP evaluators that the business data will not be locked away in a black box. Of course without the "helper" app the cost of entry often seems high, but I haven't found anything I can't reverse engineer after building the right tools for the job. And of course there is plenty of action in the BI and DW arena to reinforce the trend of using an "SQL" layer.

> Programmers will always gravitate towards viewing the data in "their
> databases" as their private bailiwick, and insist that users of the data
> access it through their own API. Learning SQL is certainly better than
> learning a hundred programmer's different APIs.

Definitely - but regardless of the merits of any tool a determined individual will still find a way to cross thread (or tear the head off) a stud.

Cheers, Frank. Received on Mon Aug 22 2005 - 14:07:54 CEST