"Frank Swarbrick" <Frank.Swarbrick@[EMAIL PROTECTED]
> wrote in message
news:485BF5A5.6F0F.0085.0@[EMAIL PROTECTED]
> >>> On 6/20/2008 at 2:49 AM, in message
> <69KdnXkzOICq8sbVnZ2dnUVZ8tDinZ2d@[EMAIL PROTECTED]
>, Roy
> Hann<specially@[EMAIL PROTECTED]
> wrote:
> > "Frank Swarbrick" <Frank.Swarbrick@[EMAIL PROTECTED]
> wrote in message
> > news:485950E4.6F0F.0085.0@[EMAIL PROTECTED]
> >> The following is a message from a fellow programmer to a group of use
> > that
> >> are involved in table design:
> >>
> >> "We are planning on creating 'account opening sources' lookup table
to
> >> store
> >> 'account source' codes and corresponding descriptions. Problem with
> >> storing
> >> this data in a dedicated table is that as we go on we'd end up with
tens
>
> >
> >> and
> >> possibly hundreds of lookup tables.
> >
> > So what? Tables aren't rationed.
> >
> > The desire to conceal complexity is not the same as the desire to
remove
> >
> > complexity. The former is counterproductive while the latter is
> > praiseworthy. What you describe is a a desire to conceal what is
going
> > on.
> > How does that help anyone?
>
> Honestly, I don't know his reasoning. We're going to have a discussion
next
> week about it, and I'm sure more than one of us will shoot it down.
Until
> then I'm not sure what is real concern is.
Roy's response is excellent! Concealing complexity is not the same thing
as
removing complexity. I wish I'd said that... and I probably will!
>
> > Maybe the implicit concern is not the number of tables in the database
> > but
> > the amount of code required to maintain them. That's a programming
> > problem.
>
> Hmm, I don't think that's it. Why would it be any more work? If
anything
> it's more work for the DBA, because he has to define the new table!
>
One of the values of a database, as compared with a simple files solution
is
that the data is do***ented, at least to some extent. When a new type of
lookup table is to be created, it most often means that a new type of data
and a new entity exists in the system.
The people who want to bypass the DBA in the creation process thereby
inherit the responsibility of making the new type of code useable by
everyone who might need to know about it, and therefore the
responsibility
of do***enting the new data type. Often, when programmers are able to
create and store new types of code on the fly, in an EAV -- OTLT type of
design, the only place where knowledge about the data is kept is in the
brains of the programmers.
There are a few cir***stances where this works out ok, but most of the
time
it ends up causing a severe problem when people other than the original
programmers try to make use of the data.
Coding a lookup from an EAV table involves a more complex set of criteria.
EG:
where code = "CO" and code_type = "AIRLINE_CODE"
If different code types are stored in different columns (and therefore
probably in different tables) you only have to look up the code, and
look
in the right table. So it's adding complexity to the code, while reducing
complexity in the table structure. More than one programmer has commited
the bug of leaving off the second part of the criteria above.
> > Get the programmors off their ***** and tell them to learn how to
write
> > dynamic SQL.
>
> Hmm, better watch it here. :-) Both he and I are programmers.
> Though I'm not sure where dynamic SQL comes in to play here.
>
I'm not sure how dynamic SQL applies either...
|
