Re: Expert user vs. Internals Expert

"Rich Ryan" <rryan_at_cshore.com> wrote in message news:iRLcg.76133$_S7.19340_at_newssvr14.news.prodigy.com...
> To be considered a relational database expert ( in the eyes of a potential
> client) , is relational theory more important than knowledge of the
> internals and administration of a particular implementation(Oracle, MS SQL
> Server, MySQL)? Or the other way around.
>
> Rich
>
>

It depends on what you mean by "expert".

If the expert is hired for the sake of advice and knowledge transfer, and not for the sake of work product captured in "deliverables", then knowledge of theory is quite important up to some level.

That level depends on what the client is trying to do.

It takes far less knowledge of theory to design a decent database than it does to develop a superior DBMS, or design a new language for manipulating and exchanging data. Many people in c.d.t. are doing the latter, and have far more need of a good grasp of advanced theory than the mere designer does.

Having said that, database design benefits a great deal from knowledge of at least rudimentary theory. I can't speak to what the younger generation is learning in school, but I can speak to my own learning curve. Unfortunately, a great many people my age were very seasoned programmers, in any language from COBOL to PL/1 to C++ when they first got involved in database design.

In the course of programming, they got used to the idea that data definitions were dull, boring, tedious, and inconsequential. In reality, nothing could be further from the truth, at least as far as the inconsequential part is concerned.

As a consequence, many of the databases designed, by presumed professionals, over the years have been designed incredibly poorly. And many of these incredibly poor designs have merely convinced some neophytes that all databases basically suck. It's not true. One can get a huge bang for the buck out of simple and sound design of a database, and frequent re-use of the same data to solve mulitple problems in the same general space.

Product specific knowledge is very important, during the latter stages of design, and during implementation later on. Unfortunately, too many applications and databases are designed around the product, rather than designed around the requirements themselves. The result is less portable, but generally no better, than a project that minimizes and localizes product dependancies. Received on Wed May 24 2006 - 01:40:31 CEST