HP3000-L Archives

October 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Eric J Schubert <[log in to unmask]>
Reply To:
Eric J Schubert <[log in to unmask]>
Date:
Sun, 6 Oct 1996 14:45:38 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines)
Data Codification is when a table of "accepted" responses is created and
given a particular coded value.  A simple example is a US State table  where
variable in length state names are given two character "codes", such as "IN"
for Indiana.

In the classic "disk starved" days of not too long ago  - it would be very
common practice (even mandated by standards?) to use "codification" tables
that refer back to a pool of longer length literal descriptions.

In data processing terms, a "coded" field in a row represents:

 - A foreign method not known to the DBMS or RDBMS access methods.

 - A foreign key that represents an artificial hierarchical level.

 - A disk saving device but at the cost of I/O and CPU foreign translation
methods for reporting.

 - Difficult to manage archival trail when literal values are changed in a
table but codes remain unchanged.

 - Historical analysis requires the rules set to be codified by the
archivist, which are parts of programs or general descriptions within
dictionaries.

 - In classic application programs - the application logic must decode the
values stored on the database to display on a report or terminal.

***

Now it is 1996 and I want to design a two tier RDBMS centered system.

- Are codification practices of the past era applicable anymore, i.e.,
should I design for unloaded fields but maintain integrity by literal checks?

- Are there methods that maintain integrity on the SQL server without
codification of foriegn keys (resulting in severe performance hits?)

- Should data field expressions be completely self contained by the
capabilities of the RDBMS?  (not codify overloading "funny" or "foreign"
logic on the field values?)

- I can understand the need sometimes to create a coded data field - but
should both the code and description be stored within the same row
(eliminates the need to apply foreign rules to the field and make archival
easy)?

- Is simplicity greatness?  Should there be a trade off of data integrity
and complexity?

Any thoughts on these matters welcome.
---
----------------------------------------------------------------
Eric Schubert               Excellence in Service,Senior Analyst
University of Notre Dame    Office of Information Technologies
Notre Dame, Indiana USA     (219) 631-7306

 "Innovate - not imitate"

ATOM RSS1 RSS2