Re: Data Display & Modeling

"Anne & Lynn Wheeler" <lynn_at_garlic.com> wrote in message news:ur7tn64hs.fsf_at_mail.comcast.net...
> "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).

Good point and yes, I do enjoy reading such history. cheers! --dawn

> random reference:
> http://www.computerhistory.org/exhibits/highlights/hollerith.shtml
>
> --
> Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Received on Fri May 14 2004 - 15:38:20 CEST