Re: Data Display & Modeling

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> writes:
> I'm not the one who makes the distinction, although I try to work
> with the distinction when others care about it. A Date in PICK is
> typically handled as atomic (from my perspective) and that is why
> pick shops had very little work with Y2K -- they weren't splittin'
> that puppy apart all the time, but were working with an odd "days
> since Dec 31, 1967" internally stored number that simply permits the
> type of arithmetic one does with dates. It can be viewed as
> MM/DD/YYYY or in any other format, but it is not stored that way.
> So, the POSSREPs have components, but the type Date doesn't. It
> does have functions, however, so you can get the month as a logical
> consequence. So, is Date atomic or compound? I don't care what you
> call it, but don't handle it the way SQL-DBMS's or at least DBMS
> developers have done in the past, resulting in the Y2K maintenance
> costs.

note that a large part of the Y2K issues could be blamed on legacy things carried forward from tab-card-based infrastructures that conserved space in the 80character cards by representing years as two digit fields. the convention was carried forward when the 80byte card records were transferred to disk records ... especially with paradigms that effectively mimic the tabcard based paradigm with rows and columns ... where rows represent each card and the columns represent the different fields defined in a card. There were pervasive accounting oriented card-based systems ... with unique card for each account and various fields associated with the account carried in columns of the 80byte card record. This paradigm has perpetuated up until now in various disguises and is still used extensively.

The issue to conserve space by representing year fields as two digits (or in some cases even a single digit as carry over from the tab card days) was somewhat mitigated by the rapid growth in large disk spaces and drastic reduction in the disk price per megabyte. However, it had been institutionalized by hundreds of billions of dollars worth of applications software (or at least that was the original development costs) that embedded various space-conserving encoding methods.

I wouldn't say that it is specific to SQL-DBMS or other various implementations ... it is common to all deployments that perpetuate the tab-card paradigm and legacy (the legacy dates back to at least the 50s for relatively wide-spread deployment ... and has its roots with events like the 1890 census).

random reference:
http://www.computerhistory.org/exhibits/highlights/hollerith.shtml

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/