|
Walden, In a message dated 98-04-03 20:07:25 EST, you write: <<snip>> > However, while I agree with your PF views I don't completely agree with you > Field Reference File views. FRFs should define a domain, not a data type. I > agree that the customer number in the order file and the customer file > should refer to the same field in the FRF, but why would you have all the > dates refer to a single date field? A date is a data type, not a domain. > What in the world does a customer order date have to do with a item > expiration date? I know, I know. From a "database purist" standpoint, dates shouldn't be in the field reference (you should just use a date data type, as the same type of date should not be replicated across files under normalization rules). From a "database realist" standpoint, however, I must disagree. Files, fields, and parameters have become too numerous in today's complex software packages to adequately track and evaluate them. BPCS provides a good case in point -- all dates passed between the newly modularized inventory transaction processing system are eight positions, with two exceptions (which we've had to manually correct ourselves). Had the latter been externally referenced, they wouldn't have been missed. While I realize that Y2K _MAY_ present a unique instance of this, who knows? The US, Canadian, or EU governments could mandate at some point that all dates for international commerce be reported to them in "EBCDIC packed, reversed Polish notation, consisting of 27 decimal characters". Some person takes power with a cousin that does programming, and there's no telling what can happen. Simply "flipping a switch" in the data dictionary under this circumstance would certainly be easier than what we're going through now! A date could, indeed, constitute a domain in this circumstance... JMHO, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@aol.com "Never go to bed mad. Stay up and fight." -- Phyllis Diller +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.