Subject: | |
From: | |
Reply To: | |
Date: | Sun, 6 Oct 1996 14:45:38 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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"
|
|
|