Users vs Developers

From: Marc Mnich <g592436_at_mip.lasc.lockheed.com>
Date: 23 Sep 1994 21:51:42 GMT
Message-ID: <35vile$kgl_at_pong.lasc.lockheed.com>

In article <34262_at_uswnvg.uswnvg.com>, kimmng_at_uswnvg.com (Kim Ng) writes:
> Terry Veli (g592291_at_mip.lasc.lockheed.com) wrote:
> : Should engineers in a production environment be allowed to create tables?
 

> : This issue has created quite a bit of controversy within our group.
> : We have a development lab where database design and application development
> : takes place. Once completed and tested, the database and applications are
> : moved into production for data loading and application use by the engineers.
>
> In general, I personally will not allow this. This encourages sloppiness.
> Eventually, you may end up with a big mess such as data integrity and
> referential integrity problems (just to name 2). If they insist on doing
> this, tell them to use a spreadsheet. Remember, you are talking about
> production system, not development.
>
> -----------------------------
> Kim Ng
> (Just a low life contract programmer. Thus, my clients won't adopt my views.)

There appears to be a strong "us vs. them" mentality developing here. This thread has included talk of rights vs. privileges concerning data and schema, "allowing" of users to create tables, etc. What is going on here? I see the manifestation of an adversarial relationship between database designers and users rather than one of teacher/student or consultant/client.

One of the essential principals of SQL and relational database theory is that by moving to a higher level language and data design, the tools become more powerful and useful at a lower user level. (If this does not yet apply to the engineering user level, it will soon.) Designers should be aware of this evolution and adjust their attitudes. The real value in the individuals who design database schemas and applications is in their expert knowledge of how best to do this with our current tools. Their job should therefore be to disseminate this knowledge wherever and whenever appropriate to as many as are capable of understanding and using it. The hoarding of knowledge may be beneficial in the short run, especially for 'building empires' and job protection, but over time will less benefit the organization as a whole. Certainly, as the database tools evolve, designers will eventually be unable to maintain their strangle-hold on the ability of users to access their own data.

I believe a valid concern here _is_ the issue of accessibility vs. data integrity. Obviously, accessibility doesn't matter without data integrity, but so much data is currently in a state of "deep freeze" that something is bound to change. With users concerned with accessibility and database designers and administrators obsessed with integrity, the inherent tension between the two will give rise to major changes in the tools. It already appears that there is a general shift away from integrity as the critical issue to accessibility. New, higher-level tools are resulting in greater automation of integrity, bringing the "power" to a broader and lower level of users.

The question that was originally posed was one of database designers "allowing" engineers to create tables in a production environment. If the engineers in this example are capable of using the current set of database tools to their advantage, why not let them? If they encounter difficulty in maintaining integrity in their tables, then why not watch over them and help them correct their mistakes? Why not answer their questions and teach them how to use these powerful tools? Why not share with them the knowledge that will promote the team rather than the individual group?

I argue that database designers should act as the disseminators (rather than the keepers) of knowledge. Although a transformation in influence and status will occur, the pay off will be in terms of a broader and growing knowledge base among the users. I believe this change is inevitable and highly beneficial to the whole.  

  __^__                                                          __^__
 ( ___ )--------------------------------------------------------( ___ )
  | / |                                                          | \ |
  | / |                     Marc A. Mnich                        | \ |
  | / |              Lockheed Aeronautical Systems               | \ |
  | / |                        Company                           | \ |
  | / |                                                          | \ |
  | / |                    Marietta, Georgia                     | \ |
  | / |                      404-494-0485                        | \ |
  |___|                                                          |___|

 (_____)------------ g592436_at_mip.lasc.lockheed.com -------------(_____) Received on Fri Sep 23 1994 - 23:51:42 CEST