>>> 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.
> 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!
> 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.
Frank
|
