Bruce, I'm with Larry.
I inherited a design in 1991 that had three such "master lookup tables" - two being honest-to-goodness master data (across manufacturing locations) with slightly different column structures (a bane to this day! They should have been one table ...) and the other containing "local" master lookup data. This was done because of the 80-table limit. Had this not been done, the three tables probably represent 30 other tables, and there just weren't enough tables available. So I understand why it was done at the time. Problem is, by the time the 80 table limit was no longer an issue, changing the structure would have involved reworking every form, report and piece of code, and by that time our lines of code count was well over 100,000. That doesn't mean I like it - I just understand why it was done. But, if I could start from scratch, I'd never, ever use such a device. Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Chitiea Sent: Friday, September 03, 2010 13:28 To: RBASE-L Mailing List Subject: [RBASE-L] - Schema Design Question: Look-ups All: Look-up tables proliferate like computer cables. Remembering my kids' names is hard enough. Wondering if there's a simpler approach, balancing coding complexity with performance: Anybody have thoughts/experience regarding two approaches: 1) individual look-up tables - each dedicated to a specific 'idea' (category); 2) a master look-up table - all 'ideas' contained within a category field - look-ups being performed through where-clauses targeting the specific category. zMasterLookUpTable zCategory - (Indexed) Where-clause target zData - (Indexed) Data values zSortOrder - Category-data sort order Just wondering. Appreciating all you all do for all of us, bruce chitiea safesectors inc
