tried to answer this earlier on, but my connection failed
here's a longer discussion
--------
its not a question of reducing the size of the database - a database is what it is
however, in general the clients table should merely store a permitlookupid, which should be the primary key of the permitlookups table, and not the other details form the permit table
whenever you need to know the permit type, and location, you then obtain these by dereferencing the pemit lookup.
however, IF the permit table has multiple locations for each permit type, then proper denormalisation might even indicate a further deconstruction of the permit table, to store the permit types separately, (and maybe the locations separately) Assuming the permit types are text, doing it this way prevents erorrs arising by bad entry of the permit type, or location data, and restricts users to entering only certain particular values.
(eg by misspelling, as this might cause you to have multiple versions of what is really the same entity)
so you MAY really need this set up
clients(client detaisl as you have them, permitlookup)
permittypes(ptypeid, ptypedesc)
permitlocations(plocid, plocdesc)
permits(permitid, ptypeid, plocid)
where the matching colours correspond to the cross-refs
Note that you certainly increased efficiency with this setup, because of the use of ids/KEYS in the lookup tables - the id's (KEYS) should generally(always) be long integer numbers.
a) size saving, as longints are smaller than text
b) speed increase, as longints are easier to handle than text
c) importantly - data independence, as you can change the description of the permit type etc WITHOUT it impacting on your database at all - since other data is not referring directly to the description, but to the index value. If you dont have this disconnection, then EVERY time you change a text value, it has to also change everywhere it is stored - now you can do this with cascading updates, but i am sure you can sense that is not a desirable feature.
