Re: Modelling problem

Hi Tobin

Good point. So far, the represented data / domains in version a was textual information, so I didn't have that problem.

Regards,
Stefan

Tobin Harris schrieb:

> Hi there,
>
> This is just my 2p's worth...
>
> If the domain has a small set of values, such as gender for example, then it
> my be prefereable to use a CHECK constraint on the column. For example
> "value in ('Male', 'Female', 'Unknown')". You could achieve a similar goal
> by creating a DOMAIN called Gender to enforce domain restriction, although
> not all databases support this.
>
> If you are looking at bigger sets of values in a domain and/or ones that may
> frequently change, then look to put these in a lookup (utility?) table (your
> option b).
>
> Option a) sounds a little obfuscated to me, unless I've misunderstood. For
> example, you say you can specify the valid values for each domiain in your
> big table, but then how do you accommodate for one domain that consists of
> numbers, and another that consists of strings? You might end up having to do
> some type-casting, which is a bit of a kludge?
>
> HTH
>
> Tobin
>
> "Stefan" <stefan.jahnke_at_bov.de> wrote in message
> news:ah41kp$pt7h6$1_at_ID-14135.news.dfncis.de...
> > Hi list
> >
> > The problem is about how to deal with look up tables and domain codes.
> >
> > Aproach a)
> >
> > Have one big table containing all possible domain types (like gender,
> >
> > account type, organizational unit etc.) and one even bigger table
> containing
> >
> > all the possible values for those domain types. The tables that use these
> >
> > types actually reference the value they should contain.
> >
> > Aproach b)
> >
> > Have "standard" look up tables for everything, for example have a table
> like
> >
> > organizational unit, which will be referenced by tables like employee via
> >
> > foreign key to link to the unit the emp. actually works for at this
> moment.
> >
> > I feel more comfortable about aproach b. Now people might say "Why ?" and
> I
> >
> > might say "Normalization ?!" and they might say "What's that good for if
> >
> > aproach is much easier to implement and blahblah....".
> >
> > Any ideas regarding pros and cons for both aproaches ?
> >
> > Regards and TIA,
> >
> > Stefan
> >
> >
> >

--

Stefan Jahnke
Consultant
BOV Aktiengesellschaft
Voice: +49 201 - 4513-298 (Germany)
Fax: +49 201 - 4513-149    (Germany)
mailto:stefan.jahnke_at_bov.de
mailto:stefan.jahnke_at_glance.ch