[AccessD] OT a little - Code Tables

I think it was bad design due to the limitations of some of the DB products
of the time.

Also, another reason it was done was for the end user's sake. Basically
there would be one table with lookups and values and the user could add or
edit new lookups types and values which would be loaded to a UI form via a
DB View.  Although it could have been done using other methods, it was one
method of accomplishing something that needed to be done. I didn't like it
back then and I dislike it even more now. I migrated data from the DB
(Informix) that held this methodology into a normalized SQL Server DB - I
had to set up many filters to get the lookup tables migrated! And that
wasn't the only non-standard methodology used in the Informix DB :o(

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, April 24, 2007 10:55 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] OT a little - Code Tables

For those who care about theory, this model is a definite no-no. A table
(relation) is a collection of like entities, and since there is no
observable penalty for the number of tables (unless it goes into the
thousands), then IMO it is asinine, not to mention theoretically unsound, to
use one table for several purposes.

Assuming that you choose the one-table route, then you must create views or
UDFs to isolate the collection of interest. Given the overhead involved in
doing that (and the more rows, the more overhead), what do you gain by
stuffing a bunch of unlike entities into a single table?