Re: Abbreviation List Tables Design, aka OTLT

Hi
The sort of things that we decide don't need their own table include some
60+ items over a system.
For example
Tank Location
TL*L Left
TL*R Right
TL*B Back of House
Credit Rating
CR*0 Full Credit
CR*1 COD
CR*2 Cash only

Credit card type
CC*MC Mastercard
CC*VS Visa
CC*99 Direct Debit

These list easily in a quick lookup and from TCL plus they translate easily
with a simple dictionary.
If they were all buried in one item in a file full of such items then the
translate dictionary would not be straight forward. In fact it is near
impossible without a Basic subroutine. The addition of Basic calls is a
relatively recent addition plus disk space used to be important. Also
opening files used to be a very time intensive exercise. I have no doubt
many of these practices could be varied however when a package has been
developed over 25 years there has to be a very good reason to change it.

I note Bruce's example and this could be achieved in the way just described
in a normal listing. I assume that he has collated the information so that
he can rapidly retrieve it without listing the whole master file. In fact a
perfect example of how many MV people denormalise data to get speed of
response. A fact I referred to on your first blog but nobody took it up.

Personally I am currently revisiting the whole area with the intention of
just sending invoices out to Excel and using pivot tables so the client can
play as much as they like. I shall still insist that they balance the
totals before calling me. Interestingly there was a seminar on this very
subject just last week - I must work out how I can get on to these seminars
using my satellite/isdn connection.

Tony used examples such as companies. I would never have considered these
as suitable for this sort of treatment as they are the sort of item that
would always require significant detail of their own.

Regards
Peter McMurray
"dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
news:1137623447.087400.139090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Excalibur wrote:
> > Hi Dawn
> > We use this all the time for those umpteen little things that need to be
> > specified but do not need their own table.
>
> There's the rub. What do you mean by "do not need their own table".
> By what criteria do you decide that something needs its own table?
>
> > Each of our major package
> > components has a Descriptions file, the key is a two part attribute with
a
> > couple of characters indicating the grouping and the second part being
the
> > item specific key.
>
> I'm not tracking why a two-part key unless you are classifying your
> code files in some way such as FINANCIAL*VENDOR-TYPES. Or are you
> normalizing your file of files so that you have the key as
> VENDOR-TYPES*GOV with the description field being Government or some
> such?
>
> > This way the client can easily add new types of a particular thing and
all
> > the programs will instantly recognise it.
>
> How would this be different from users adding new records to a file for
> each type of thing, given that the programs are only going to recognize
> the "things" that are defined in either case? In other words, even if
> you have a program that permits users to add a new "code file" for
> example, VENDOR-STATUS, no program is going to recognize those codes
> until they are set up to look at the VENDOR-STATUS record for the
> codes, right? I'm missing something.
>
> > We of course do not let the
> > client define the prefixes as we need that control and we do not let
them
> > access system control items.
>
> Instead of adding a prefix, you could add another file, right? If your
> program asked for a file name instead of a record name, wouldn't that
> have the same effect? I'm not actually challenging you because I think
> you are wrong, but because I think you are right in doing this, but I
> don't know why.
>
> > It has another benefit, one can rapidly list all those odd control
headings
> > simply by sorting by prefix.
>
> Yes. Good one. That has to do with the housekeeping of knowing what
> type of files you have -- most or all of the code files in one place
> means you and users can easily make a listing of them all, without
> changing the report when new ones are added.
>
> > We also have another Control file for those elements that the system
must
> > keep track of that has a variety of items with different types using
> > appropriate keys. The client is not allowed near this.
>
> Yes, often called a control file or perhaps parameter file. These can
> be killers for normalization.
>
> > I have worked on a lot of disparate systems over the last 30 years and I
> > cannot remember one that did not use this method.
>
> The file of files method? Yes, that is what I thought. While
> considered poor practice in the relational world, I suspect it is
> standard fare (from what I have seen) in MV systems. Thanks. --dawn
>
> > Regards
> > Peter McMurray
> >
> >
> >
> > "dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
> > news:1137606300.956463.129220@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > There have been a number of discussions in various database-related
> > > forums about what is sometimes referred to as OTLT or One True Lookup
> > > Table. It is almost always dismissed as a terrible design by
> > > relational or SQL folks, likely for good reasons if you are thinking
in
> > > terms of constraints on attributes.
> > >
> > > However, in the MV world, I have seen this design pattern several
times
> > > and was wondering how pervasive it is and whether it is considered
good
> > > design. My inclination is to think that it is a good way to design an
> > > MV solution. Something like:
> > >
> > > LIST DICT ABBREVLISTS ...
> > > @ID.......... FORMAT S/M ASSOC
> > > @ID 10L S
> > > abbrev 10L M ABBREVS
> > > shortDesc 20L M ABBREVS
> > > longDesc 60L M ABBREVS
> > > instructions 10L M ABBREVS
> > >
> > > Then code lists for everything with a "reasonable number of entries,"
> > > such as status codes, marital status, state codes, etc can all be in
> > > this one file, each with a different record ID.
> > >
> > > Do you/your company use this approach? Would you consider this a
> > > Pick/MultiValue best practice even if it is not a good practice in the
> > > relational world? Why or why not? What are the pros and cons to
using
> > > this approach?
> > >
> > > Thanks. --dawn
> > >
> > > P.S. I don't know yet if I'll write on this topic, but because
> > > information from anything I read these days could get into my blog,
> > > I'll state that overtly here and indicate that I would not quote
anyone
> > > from a list or newsgroup without first asking them.
> > >
>


.

Relevant Pages

  • Re: Abbreviation List Tables Design, aka OTLT
    ... access system control items. ... It is almost always dismissed as a terrible design by ... > Then code lists for everything with a "reasonable number of entries," ... > such as status codes, marital status, state codes, etc can all be in ...
    (comp.databases.pick)
  • Re: Abbreviation List Tables Design, aka OTLT
    ... example, VENDOR-STATUS, no program is going to recognize those codes ... > access system control items. ... It is almost always dismissed as a terrible design by ... >> Pick/MultiValue best practice even if it is not a good practice in the ...
    (comp.databases.pick)
  • Re: Havent done anything real with OOP yet.
    ... It's probably not quite design, ... but searching and sorting and that sort of thing is still nice to ... >> simulation of a temperature controller. ... >> temperature measurement, the control loop, and the voltage output to the ...
    (comp.object)
  • Re: Abstract User Control
    ... OK - I need a design surface to hold toolstrips, a status strip, another control based on a Rich Text Box. ... With that sort of variety I think a User Control is probably the way to go. ... If I understand you correctly, the only difference between the plain text and RTF versions is in fact the handling of the formatting, then presumably that means you don't need to design those type individually, and so having an abstract base class isn't a problem. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: 2001 Grand Caravan Climate Control diagnosis and code reset
    ... I was able to diagnose the back up lights. ... The BCM was the culprit ... Have you tried to access faults codes from the climate control Module ...
    (rec.autos.makers.chrysler)