HP3000-L Archives

October 1995, Week 2

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:
Tony Furnivall <[log in to unmask]>
Reply To:
Tony Furnivall <[log in to unmask]>
Date:
Wed, 11 Oct 1995 08:04:06 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (30 lines)
Wirt Atmar <[log in to unmask]> writes:
 
>If the character position of a numerical digit has even the remotest
>possiblity of meaning something to someone, it is not merely a mistake to
>store that number as a numeric field dataitem, it is a sin against God, man,
>nature, machine and beast.
 
Of course the fact that every digit in every numerical field means something
to some may tend to reduce the impact of your elegant rhetoric! I agree that
omportant semantic constraints should not be coded in non-eye-readable formats.
This is *exactly* the reason why we generally code our dates in the internal
packed decinal format I describe elsewhere.
Our experience has been that when people wnat to do do extracts of data over
date ranges for comparison, they are generally far more interested in comparing
equivalent date ranges (week 34 of the year, all of May except Memorial Day,
etc)
rather than the simple 'anything with a '05' in the thrid and fourth digits.
This type of data analysis is anathema, and while it is indde 'holier than
thou'
to provide the means to impede such simplistic thought processes, it is a
reasonable expression of our values.
 
Any date which is used not only as a date but also as a Key field is always
coded
as a display item (Generally PIC X(8), but with a 7 digit DayOfYear structure).
All other dates, however, are simply dates nothing more nothing less.
 
I'd be interested in hearing your thoughts!
Tony.

ATOM RSS1 RSS2