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: [email protected] > 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 > > [email protected] > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > 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/
