|
One problem i can see there is if any update, delete, add is performed to the file. Another way is perhaps to use a user index (not in QTEMP) and add a trigger to the file for updating the ----- Original Message ----- From: "Wilt, Charles" <CWilt@xxxxxxxxxxxx> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> Sent: Friday, May 06, 2005 2:53 PM Subject: RE: Normalization was Left AS/400 and Returned > An option to consider that hasn't been explicitly mentioned... > > Encapsulate the I/O to the data in a service program. > > Have the service program load a static array the first time any procedure in the service program is called. > > Now it really doesn't matter how the data is stored. Instead of a program chaining to a file to find out if a particular day is a workday or loading it's own array, you'd call IsAWorkday(date). > > You could even have procedures that returned an array for an entire week, month or year if needed. But more useful perhaps would be a procedure in the service program like GetWorkdays(fromDate, howMany) that returned an array of dates. > > Just my .02 > > Charles Wilt > iSeries Systems Administrator / Developer > Mitsubishi Electric Automotive America > ph: 513-573-4343 > fax: 513-398-1121 > > > > -----Original Message----- > > From: midrange-l-bounces@xxxxxxxxxxxx > > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Pluta > > Sent: Thursday, May 05, 2005 8:08 AM > > To: 'Midrange Systems Technical Discussion' > > Subject: RE: Normalization was Left AS/400 and Returned > > > > > > > > And I understand your preference. Checking every date by > > doing a CHAIN > > or SETLL on a file is easy. I think part of my bias is that > > I come from > > a scheduling background, which means I need information for periods, > > rather than single days. I might have to schedule an operation to run > > over 10 days, and thus I'll have to know all the working days. By > > reading a one-year array once, I'm covered and I can schedule all the > > work for that item. > > > > With a one-record per date approach, I'll be doing lots of > > I/O, over and > > over again (unless I read the data from the file into an > > array, at which > > point your argument about how hard it is becomes moot). > > > > I guess my point is that I think you need to look not only at the data > > but also at how it is used when determining the normalization of a > > database. > > > > Joe > > > > -- > > This is the Midrange Systems Technical Discussion > > (MIDRANGE-L) mailing list > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > > or email: MIDRANGE-L-request@xxxxxxxxxxxx > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/midrange-l. > > > > > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.