RE: Normalization was Left AS/400 and Returned

Different ways to skin a cat.  Personally, I love the idea of an array
in the file because it makes it really easy to overlay one calendar with
another.  One record per date gets a bit I/O intensive when you need to
plan an item and you can have overrides at various levels (first you
have a company schedule, then a site schedule, then a specific item
schedule).

Since I'll probably store the information internally in an array anyway
(in order to keep from having to read the file over and over), I'm not
as worried about the Julian date issue, but I can see how it might be
problematic to someone who can't handle date arithmetic.  But that's as
stupid of a programmer as I'll allow for in a production shop.  I don't
buy the excuse that an array field is too hard to understand.  If your
programmer can't figure out what a field that is 366 characters long
with a text of ('Flags, one per day') does, then they really need to
broaden their employment horizons.

And I'm going to get out of this conversation before I get really worked
up and turn it into a tirade about the general dumbing down of the
industry.  Suffice it to say that some of the things people on this list
find too difficult are things a junior programmer would have been
expected to handle 20 years ago.

Joe


> From: Fisher, Don
> 
> I'd store it by warehouse and date.  Why?  Because a maintenance
> programmer
> can look at the file and have a very good idea how it's used.  Using
an
> array, the programmer will have to figure out what element of the
array
> should be used by examining the program code.  Then there's the issue
of
> having to convert a perfectly good date to a julian representation in
> order
> to extract the correct array element.
> 
> Just my opinion, of course.