Good practice for lookup tables?

[Koen]

Hi all,

My application uses a lot of lookup tables.
I've splitted the frontend (forms, reports, etc) from the backend (data).
The database has around 10 different users.

The values in the lookup tables are not likely to change.

Question 1: Should I include them in the backend (with rest of data) or the
frontend?

Question 2: What's more efficient, have all the lookup values in separate
tables or combine them in _one_ table?

Thanks,

Koen

[DFS]

"Koen" <[e-mail]> wrote in message
news:Xn*********************@194.109.133.20...

Hi all,

My application uses a lot of lookup tables.
I've splitted the frontend (forms, reports, etc) from the backend (data).
The database has around 10 different users.

The values in the lookup tables are not likely to change.

Question 1: Should I include them in the backend (with rest of data) or the frontend?
I recommend the backend, whether they're likely to change or not. If
they're in the backend, you can (and should) use them to enforce referential
integrity on the master tables.

If they're in the frontend, and even one record change is required, you have
to redistribute the app.

Question 2: What's more efficient, have all the lookup values in separate
tables or combine them in _one_ table?
Separate table for each, because of the flexibility you need due to

1) differences in relationships with other tables in the system
2) different structures
3) different field types
4) different field sizes

Not to scare you or insult you, but I inherited a system once where the
previous Access developer combined 8 lookup lists into one table with 15 to
20 columns. Columns 1 and 2 were one lookup "table" with 10 rows. Column 3
was a lookup "table" with 80 rows. Columns 4 and 5 were a lookup "table"
with 5 rows. etc.

They fired him for incompetence.

I've seen multiple lookup "tables" combined into one, using a column to
indicate the type of lookup...

LookupCategory
LookupValue

....but I recommend against it.
Thanks,

Koen

[Fletcher Arnold]

"Koen" <[e-mail]> wrote in message
news:Xn*********************@194.109.133.20...

Hi all,

My application uses a lot of lookup tables.
I've splitted the frontend (forms, reports, etc) from the backend (data).
The database has around 10 different users.

The values in the lookup tables are not likely to change.

Question 1: Should I include them in the backend (with rest of data) or the frontend?

Question 2: What's more efficient, have all the lookup values in separate
tables or combine them in _one_ table?

Thanks,

Koen

I would agree pretty much entirely with the post from DFS. However, I
*might consider* combining lookup tables if the structures were identical,
eg:

tblJobStatus = JstID, JstCode, JstName
tblCompanyStatus = CstID, CstCode, CstName

Might be combined into

tblStatus=StsID, StsCode, StsType, StsName

But in general not. You don't mention the number of these lookup tables you
have, nor any variations in structure.

Fletcher

[Koen]

"Fletcher Arnold" <fl****@home.com> wrote in
news:bt**********@titan.btinternet.com:

I would agree pretty much entirely with the post from DFS. However, I
*might consider* combining lookup tables if the structures were
identical, eg:

tblJobStatus = JstID, JstCode, JstName
tblCompanyStatus = CstID, CstCode, CstName

Might be combined into

tblStatus=StsID, StsCode, StsType, StsName

But in general not. You don't mention the number of these lookup
tables you have, nor any variations in structure.

Fletcher

I have around 25 lookup tables. Their structure is always the same: ID
(number), Name (text). The can tables can be combined into one table by
adding a TypeID column.

I was thinking about efficiency of table handles and performance... Let's
say you have a form with 8 lookup fields. Maybe it would be more efficient
to load the single lookup table once. Maybe I am wrong...

Kind regards,

Koen

[Fletcher Arnold]

"Koen" <[e-mail]> wrote in message
news:Xn*********************@194.109.133.20...

"Fletcher Arnold" <fl****@home.com> wrote in
news:bt**********@titan.btinternet.com:

I would agree pretty much entirely with the post from DFS. However, I
*might consider* combining lookup tables if the structures were
identical, eg:

tblJobStatus = JstID, JstCode, JstName
tblCompanyStatus = CstID, CstCode, CstName

Might be combined into

tblStatus=StsID, StsCode, StsType, StsName

But in general not. You don't mention the number of these lookup
tables you have, nor any variations in structure.

Fletcher

I have around 25 lookup tables. Their structure is always the same: ID
(number), Name (text). The can tables can be combined into one table by
adding a TypeID column.

I was thinking about efficiency of table handles and performance... Let's
say you have a form with 8 lookup fields. Maybe it would be more efficient
to load the single lookup table once. Maybe I am wrong...

Kind regards,

Koen

I believe that there will not be much benefit in terms of speed to be gained
from combining the tables into one. Certainly the practice of moving these
tables from the back end to the front, as you mentioned earlier, is
generally more trouble than it's worth.

One benefit of having a single table would be the simplicity of design - if
you have to understand a database schema then 1 table is better than 25.
Also, having a single user interface to manage these lookups is very useful
but since the table structures are the same, you could create one lot of
forms, reports etc that could handle all 25 tables anyway.

The area I would consider the most important is enforcing referential
integrity - which may require special attention. If you had a table like
the status table below:

StsID StsType StsName
1 Company Small
2 Company Medium
3 Company Large
4 Job Current
5 Job Cancelled

and had a field in another table called JobStatus which was got it's value
from StsID, then although you could enforce referential integrity at
table-level, there would be nothing to stop this field having the value of
2. This obviously does not belong since the value means 'company status:
medium'. If you had 25 separate tables this would not be an issue.

Of course you don't have to enforce things at table-level since you can use
the user interface for this and some people have argued in this group that
enforcing at table-level is not necessary, however, I believe if you can,
then you should.

I could offer further ideas, where perhaps some form of field validation
rule could help, but I'd better get back to some of my own work!

Regards

Fletcher

[Koen]

"Fletcher Arnold" <fl****@home.com> wrote in
news:bt**********@titan.btinternet.com:

I could offer further ideas, where perhaps some form of field
validation rule could help, but I'd better get back to some of my own
work!

Regards

Fletcher

Thanks! I appreciate your feedback!!

Kind regards,

Koen

[David W. Fenton]

[e-mail] (Koen) wrote in
<Xn*********************@194.109.133.20>:

My application uses a lot of lookup tables.
I've splitted the frontend (forms, reports, etc) from the backend
(data). The database has around 10 different users.

The values in the lookup tables are not likely to change.

Question 1: Should I include them in the backend (with rest of
data) or the frontend?
I think this depends on whether the tables have data in them that
is specific to a release of the front end or not. I have one table
that I always include only in the front end, because it includes
lists of reports (and information about those reports that is used
to drive a unified UI for printing reports), and that list changes
with the updates to the front end. If that table were in the back
end, users who haven't yet received the update to the front end
would be presented the opportunity to print a report that might not
yet exist in their copy of the front end.

But most lookup tables, I think, belong in the back end. Few such
lookups have dependencies on UI objects.

Some folks, though, populate local copies of lookup tables from the
back end when the application launches as a way of decreasing how
many times you have to retrieve data from the server. I've never
seen a situation in which this was worth doing.
Question 2: What's more efficient, have all the lookup values in
separate tables or combine them in _one_ table?

You might want to spend some time looking at this:

http://www.bway.net/~dfassoc/downloa...okupAdmin.html

It's a unified single lookup table to replace multiple small
lookups. It makes providing administration of those lookups very
easy.

I use it in all my applications and find it very easy.

But others fundamentally disagree with the approach as it makes RI
enforcement difficult (though not impossible if you're willing to
have it be imperfect).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

no****@nospam.com (DFS) wrote in
<vv************@corp.supernews.com>:

I've seen multiple lookup "tables" combined into one, using a
column to indicate the type of lookup...

LookupCategory
LookupValue

...but I recommend against it.

Have you ever looked at my implementation of this?

http://www.bway.net/~dfassoc/downloa...okupAdmin.html

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[DFS]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86.. .

no****@nospam.com (DFS) wrote in
<vv************@corp.supernews.com>:

I've seen multiple lookup "tables" combined into one, using a
column to indicate the type of lookup...

LookupCategory
LookupValue

...but I recommend against it.
Have you ever looked at my implementation of this?

http://www.bway.net/~dfassoc/downloa...okupAdmin.html

As slick as your Lookup Admin system is, I fundamentally disagree with
combining different data types in one text field, and would never do it in
reference tables.

Something you're missing is a status bar description of each lookup field -
you could add it as a column in your master lookup table 'tblLookup'

One nice thing I did notice: you use one subform to show all the different
lookup sets, and set the column widths and captions manually. I usually
create a subform for each lookup table, so my Access systems typically end
up with a blizzard of file-bloating forms in them.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

no****@nospam.com (DFS) wrote in
<vv************@corp.supernews.com>:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86. ..

no****@nospam.com (DFS) wrote in
<vv************@corp.supernews.com>:

>I've seen multiple lookup "tables" combined into one, using a
>column to indicate the type of lookup...
>
>LookupCategory
>LookupValue
>
>...but I recommend against it.

Have you ever looked at my implementation of this?

http://www.bway.net/~dfassoc/downloa...okupAdmin.html

As slick as your Lookup Admin system is, I fundamentally disagree
with combining different data types in one text field, and would
never do it in reference tables.

Something you're missing is a status bar description of each
lookup field - you could add it as a column in your master lookup
table 'tblLookup'

One nice thing I did notice: you use one subform to show all the
different lookup sets, and set the column widths and captions
manually. I usually create a subform for each lookup table, so my
Access systems typically end up with a blizzard of file-bloating
forms in them.

You could definitely get the benefit of the single UI by simply
applying that one principle to a structure in which you had
multiple lookup tables and used a single subform, reformatted like
that. You would, though, need a lookup table somewhere that
provided you with a list of the lookup types, unless you did
something like giving the lookup tables a custom property and using
that to populate the list.

I packaged it not so much to try to convince people to use it
wholesale, but so people could look at it and maybe get some ideas
of their own. I wouldn't expect others to do things exactly the
same way I would, but I've never had any issues with this.

An earlier version of it had a data type field, but it just became
too much work to deal with. Another earlier version had separate
fields for different kind of data, and that was a disaster. I
eventually settled on mixing datatypes as I do when I realized that
it was just a kludge on top of what was already something of a
kludge.

For me, giving up some data validation and integrity enforcement is
worth the easy of implementation it gives me, dropping the whole
thing into a new app and populating the lookup table. For me, it
vastly speeds up the basic development process as well as allowing
the addition of lookups and configuration data without having to
change the data schema. For large, live app, this can be a pretty
significant benefit.

But I understand why others would not want to use it.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc