Re: [U2] [UD] Best practices
?? Apologies if I've missunderstood the question: You need to index on the same name that's You use in your SELECT's or SELECTINDEXes to have an effect ! If You haven't written them yet use the meaningfull PRODUCT. -- mats Arnold Bosch wrote: I have a question / concern regarding the D and I types: If a D type is created (F1 below) and an I type added to the dictionary referencing this D type directly (PRODUCT below), what is the impact on indexing? For example, if an index is created on the D type, will UNIBASIC code using the I type benefit from this index? The reason I am asking this, is that we have a system with all the data tables created with D types called F1, F2, F3 etc, and all the coding is using the I types for data access. The system has NO indexes created, and even simple queries take ages to execute because of this... I know from previous posts that it is not a good idea to create indexes on fields that are TRANSed from other tables, but we can definitely benefit from indexing on some of the more-used fields in our tables. My problem is on which fields to create these indexes Type Field. Field. Field Conversion.. Column. Output Depth Name.. Number Definition... Code Heading Format Assoc.. F1 D1Product Code20LS PRODUCTI F1 Product 20LS Thanks regards Arnold Bosch IT Administrator Taeuber Corssen SWA (Pty) Ltd Email: [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
I would second all the points about maintainability and legibility being key. One additional thing I have seen on one site: Unlike the A/S type dictionaries, there is no standard way of separating base and synonym dictionaries using D types, which can lead to dictionary listing that takes forever to plough through to get to the definitions of later fields, and makes writing automated routines to build BASIC include files more complex. So the convention they adopted was to use D types for all the 'base' fields (one D type per field) and make all synonyms into I types of the form: I Base_Field_Name That way they could see the file layout more easily. I thought that was pretty smart. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Best practices
Good idea, but is there any performance penalty to using I-types like that? -- Louie On 1/29/06, Brian Leach [EMAIL PROTECTED] wrote: I would second all the points about maintainability and legibility being key. One additional thing I have seen on one site: Unlike the A/S type dictionaries, there is no standard way of separating base and synonym dictionaries using D types, which can lead to dictionary listing that takes forever to plough through to get to the definitions of later fields, and makes writing automated routines to build BASIC include files more complex. So the convention they adopted was to use D types for all the 'base' fields (one D type per field) and make all synonyms into I types of the form: I Base_Field_Name That way they could see the file layout more easily. I thought that was pretty smart. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
Brian Leach wrote... Unlike the A/S type dictionaries, there is no standard way of separating base and synonym dictionaries using D types, which can lead to dictionary listing that takes forever to plough through to get to the definitions of later fields, and makes writing automated routines to build BASIC include files more complex. So the convention they adopted was to use D types for all the 'base' fields (one D type per field) and make all synonyms into I types of the form: I Base_Field_Name That way they could see the file layout more easily. I thought that was pretty smart. Here are some things I have seen and used on UniVerse that perhaps applies to UniData as well. Using I types in the way described above seems to move the problem of noise from the D types to the I types area. Also, it incurrs additional reporting overhead as an ITYPE() function is far more expensive than an EXTRACT() function. Other approaches include using custom D types or PHrases. The letters following the D in field 1 of the dictionary defintion are treated as comments, where the first space delimits the Type from the Description. Defining additional D types is easy. One site used DP to indicate the Primary field definition and the plain D types were considered synonyms. The DP types had good descriptions for the field whereas the D types descriptions were typically silent. Use PHrases to create customized D types on the fly for use with reporting. E.g. F1 6 lines D 1 10L S TF1 2 lines PH F1 FMT 33T Of course, the PHrase solution only works with the report writer. The nice thing about both of these approaches is that they retain the performance of the EXTRACT(). Best regards, Gyle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
Louie There is, but I would imagine pretty minimal considering modern platforms. It's all in-memory handling. It just struck me as an interesting practice. Personally I tend to use separate reporting dictionaries for decluttering (i.e. physically separate dictionary files held in a separate reporting account and pointing to the live data files). That way I can keep reporting views separate and allow users to update them without affecting the live dictionaries that may be used transactionally. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Louie Bergsagel Sent: 29 January 2006 17:33 To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] Best practices Good idea, but is there any performance penalty to using I-types like that? -- Louie On 1/29/06, Brian Leach [EMAIL PROTECTED] wrote: I would second all the points about maintainability and legibility being key. One additional thing I have seen on one site: Unlike the A/S type dictionaries, there is no standard way of separating base and synonym dictionaries using D types, which can lead to dictionary listing that takes forever to plough through to get to the definitions of later fields, and makes writing automated routines to build BASIC include files more complex. So the convention they adopted was to use D types for all the 'base' fields (one D type per field) and make all synonyms into I types of the form: I Base_Field_Name That way they could see the file layout more easily. I thought that was pretty smart. Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
I have a question / concern regarding the D and I types: If a D type is created (F1 below) and an I type added to the dictionary referencing this D type directly (PRODUCT below), what is the impact on indexing? For example, if an index is created on the D type, will UNIBASIC code using the I type benefit from this index? The reason I am asking this, is that we have a system with all the data tables created with D types called F1, F2, F3 etc, and all the coding is using the I types for data access. The system has NO indexes created, and even simple queries take ages to execute because of this... I know from previous posts that it is not a good idea to create indexes on fields that are TRANSed from other tables, but we can definitely benefit from indexing on some of the more-used fields in our tables. My problem is on which fields to create these indexes Type Field. Field. Field Conversion.. Column. Output Depth Name.. Number Definition... Code Heading Format Assoc.. F1 D1Product Code20LS PRODUCTI F1 Product 20LS Thanks regards Arnold Bosch IT Administrator Taeuber Corssen SWA (Pty) Ltd Email: [EMAIL PROTECTED] Snipped... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
Use the attribute names everywhere - the only place attribute numbers belong is in D-type entries in the dictionary and in an equate table in a single basic include file. From: [EMAIL PROTECTED] on behalf of Bill Haskett Sent: Sat 28/01/2006 4:24 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UD] Best practices 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 Direct 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. [demime 1.01d removed an attachment of type application/ms-tnef which had a name of winmail.dat] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
Reusability Readability are two attributes of good software. Actually, they are also sub-attributes of MAINTAINBABILITY, which I consider the most important attribute of good software. Define once reuse. What we lack is a good standard way to examine dictionaries and their related pieces. A standard listing is very disjointed. I think Ray Jones Brian Leach both have tools they are proud of. I keep threatening to look into that, but haven't yet. Comments interspersed below. Chuck Stevenson 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* I prefer attribute names for the same reason I would name basic program variables VOID DEPOSITED instead of ATT2and ATT18. ( or, defined via a standard $INCLUDE, something like SALES.REC SALES$VOID or SALES_VOID instead of SALES.REC2 or SALES.REC(2). You get the idea.) Also, you can nest I-descriptors, referring to a calculation by name, instead of re-coding the calculation in every I-descriptor that needs it. (Caveat: for UV they have to be structured without multiple ;-delimited expressions.) The obvious concern is if a direct field definition is renamed, then all references to the old field name need to be changed. Same logic can be applied for opposite conclusion: if you renumbered the fields then you would have to rewrite all the I-descriptors that used explicit numbers. I rarely rename a field, Renumbering fields would be more rare, admittedly, but... BUT: It is NOT rare for calculations to be refined over time. Sometimes what is originally a stored value gets redefined as a calculation. Example: TAX. Suppose somebody originally defines it as a stored field, then you go interstate and it needs to be computed differently for each state. Then you're more successful, so you write a subroutine to handle Canada European tax... If you had 1 dict item called TAX and always referenced it, then it could migrate from D-item, to I-item, to I-item with called subroutine, and so on. You would _CHANGE_IT_ONE_PLACE_ recompile the dictionary. If you had coded all sundry I-descriptors referring to TAX via an extract, or later by recoding the calculating repeatedly, you're stuck with less maintainable code. This is an argument for using ITYPE() functions in programs, too. READ TAX.IDESC FROM SALES.DICT, 'TAX'... TAX = ITYPE( TAX.IDESC ) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Best practices
I would suggest a clearer naming convention for your dictionary items. When you have DATE as part of your field name, it makes sense that a programmer would expect a date to be returned. For instance, DEPDATE (or DEPOSIT.DATE) should be a data type (D), and just the date of the deposit. I suggest DEPOSIT.DATE because in an attorney's office, DEPDATE could be a deposition date. You can always shorten the name via a synonym if you wish. If you want to display deposit dates and know if the deposits were voided, I'd name the I-type DEPOSIT.DATE.VOID or DEPOSIT.DATE.STATUS so both a programmer and a user could expect to see something besides just a date. Louie Bergsagel Seattle DEPDATE 001 I The displayed deposit date (if not voided). 002 IF VOID = THEN DEPOSITED ELSE *Voided* --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Best practices
Bill, Friday, January 27, 2006, 12:24:47 PM, you wrote: BH I've been converting dictionaries from a D3 dbms and am wondering what is BH considered best practices in virtual attribute design. BH Does one build standard Direct fields first then use these fields to build BH virtual attributes (I-Descriptors) or should one use the direct field BH references, EXTRACT() or n,n,n, in virtual attributes? BH DEPOSITED BH 001 D The date of the deposit. BH 002 2 BH VOID BH 001 D Is this a voided receipt? BH 002 12 BH DEPDATE BH 001 I The displayed deposit date (if not voided). BH 002 IF VOID = THEN DEPOSITED ELSE *Voided* BH or BH DEPDATE BH 001 I The displayed deposit date (if not voided). BH 002 EXTRACT( @RECORD, 2, 0, 0 ) ; EXTRACT( @RECORD, 12, 0, 0 ) ; BH IF @2 = THEN @1 ELSE *Voided* BH The obvious concern is if a direct field definition is renamed, then all BH references to the old field name need to be changed. I rarely rename a BH field, until I started exposing the data to other data sources and was BH forced to clean up the field names. So, hopefully, this won't be an issue BH in the future. I would go with using the dict names .. that is the beauty of the dictionary . that you don't have to hardcode a position in. And if some idiot deletes 'VOID' then they get what they deserve. It is better documented using name and should be a 'required' practice in a shop. AND if for some reason you want to restructure the table then there are no worries .. always with the right opinion .. your buddy -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Best practices
My ha'pennorth (trans: two cents) 1) If you are using multi-values or multi-subvalues please use Phrases (PH items) in your dictionaries. It makes life much easier (and safer) for all. 2) Don't assume the date format on the system the software is installed is *your* date format - be explicit. I have seen systems go very wrong because dates like 11/02/ were assumed to be the 2nd of November and not what they REALLY are (the 11th of February). I am sure the converse has happened as well 3) When you take a backup make sure the database is quiesced - either STOP the database or PAUSE it (dbpause/SUSPEND.FILES ON) - (take your backup/snap/split-mirror) and then (dbresume/SUSPEND.FILES.OFF). Disaster stories illustrating *don't do it* under separate cover please: ;-' Oh the stories we could tell...(but can't due to client confidentiality). Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Best practices
Personally, I've never used either methods. Here is how I would do the I-descriptor: 001 I 002 IF @RECORD12 = THEN OCONV(@RECORD2,D4-) ELSE *VOIDED* Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 01/27/2006 03:24:47 PM: 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 Direct 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Best practices
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 Direct 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
