To me, this is an issue of readability and maintainability. If I read
'IF VOID = "" THEN DEPOSITED ELSE "*Voided*"', I can make a reasonable
guess at what it is trying to do, without knowing anyghing about the
file structure. If you use numeric references to fields, you will
probably have to do some research to figure out what the heck the
dictionary is tring to accomplish. Do your fellow developers (not to
mention future developers and even yourself in 2 years when you've
forgotten what the heck this file was for to begin with) a favor, and
use the D-type field references in your I-type dictionaries.
A corollary to this would be, "make sure you choose good names".
Bill Haskett wrote:
I've been converting dictionaries from a D3 dbms and am wondering what is
considered "best practices" in virtual attribute design.
Does one build standard "D"irect fields first then use these fields to build
virtual attributes (I-Descriptors) or should one use the direct field
references, "EXTRACT()" or "<n,n,n>", in virtual attributes?
DEPOSITED
001 D The date of the deposit.
002 2
VOID
001 D Is this a voided receipt?
002 12
DEPDATE
001 I The displayed deposit date (if not voided).
002 IF VOID = "" THEN DEPOSITED ELSE "*Voided*"
or
DEPDATE
001 I The displayed deposit date (if not voided).
002 EXTRACT( @RECORD, 2, 0, 0 ) ; EXTRACT( @RECORD, 12, 0, 0 ) ;
IF @2 = "" THEN @1 ELSE "*Voided*"
The obvious concern is if a direct field definition is renamed, then all
references to the old field name need to be changed. I rarely rename a
field, until I started exposing the data to other data sources and was
forced to clean up the field names. So, hopefully, this won't be an issue
in the future.
Any thoughts.
Bill Haskett
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
