Re: Lots of code. How many tables.

From: Keith Johnson <pickie8_at_hotmail.com>
Date: 2 Mar 2004 12:54:15 -0800
Message-ID: <bbafb232.0403021254.b4d0005_at_posting.google.com>


"ben brugman" <ben_at_niethier.nl> wrote in message news:<403239a5$0$273$4d4ebb8e_at_read.news.nl.uu.net>...
> My question how to handle the codes has been answered.
> Use a table for each codetype.

<bigsnip>

If you look at the situation from a different perspective, you could see it as providing a set of checks for the input software. Neglect for now the issue of constraints within the database, and consider how a relation could be set up which application software can query to see if a code like "M" is valid when checking "Gender".

Call the relation "Entry Check" or "EC" - one can have the primary key being two columns "EC_Type" (EG "Gender") and "EC_Code" (EG "M" and "F"). These give access to the column "EC_Description" ("Male" and "Female respectively in the prior example).

Can one of the DBMS's available use such a table/relation/relvar and provide the constraints at the database level? I haven't a clue. If one can, then redefine EC as meaning "Existance Constraint". Just make sure you don't delete all your females because someone had finger trouble and deleted "F". Received on Tue Mar 02 2004 - 21:54:15 CET

Original text of this message