Soooo - are you stating that you have CustID in only one table???
Even if you replace CustID with a meaningless immutable primary key, you would still have boatloads of fields such as PRICE that a reference back to a single place where one could inherit the attributes would reduce future maintenance costs significantly, don't you think?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Matt Olson
Sent: Tuesday, October 30, 2012 11:05 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: DDS field reference equivalent in SQL
You might want to ask yourself why you would need such functionality in the first place. In a properly normalized database design you will not have duplicitive data in multiple tables.
Better get your developers up to speed with this:
http://en.wikipedia.org/wiki/Database_normalization
-----Original Message-----
From: Stone, Joel [mailto:Joel.Stone@xxxxxxxxxx]
Sent: Tuesday, October 30, 2012 10:11 AM
To: 'Midrange Systems Technical Discussion'
Subject: DDS field reference equivalent in SQL
An important part of making field length changes easier on Iseries is to use a field reference file to inherit attributes from other fields & files.
Is there an equivalent in SQL?
Thanks
______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit
http://www.symanteccloud.com ______________________________________________________________________
--
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.
midrange.com
