"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:
[ SNIP ]
>> 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.
The other programmer's reasoning is presumably exactly what he said in his
email (the snippet that you included), the concern that there will be an
explosion in the number of tables. That he's not aware of the pitfalls of
his suggested approach is no great surprise...back in the day I surely
designed tables like this also, I'm sure all of us have.
The burden may be on you to show why the OTLT is not a good thing. Joe's
article will help, also this
(http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html),
and also this (http://www.projectdmx.com/dbdesign/lookup.aspx)
Just be
prepared to do the heavy lifting. :-) A *lot* of programmers are not
particularly database savvy, although most of us like to think we are, and
this can include senior developers and architects. You may find, for
example, that your boss (and the other programmer's boss too) likes the
OTLT
idea...best thing to do may be to weigh in on the proposal before the most
senior person (or any persons more senior than you) can open their mouths,
which gives them a chance to nod sagely and offer their own condemnations.
>> 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.
See above. My comments apply to also not pissing off your colleague. Since
he has staked some of his credibility to this flawed design, depending on
whether or not he's otherwise a decent programmer and a decent guy, you
might be doing him a favour by writing him an email, attaching references
to
OT:LT/MUCK articles, that apprises him of the downsides. That way he can
educate himself before the discussion/meeting, maybe retract the
suggestion
beforehand, and otherwise not look like a clueless idiot. If he has any
decency he'll even credit you. As it is, best case, he'll still lose some
face.
My apologies if this is teaching my grandmother how to suck eggs. I'm not
far off the mid-century mark myself, and have little patience for
point-scoring these days. I see this scenario as an excellent op****tunity
for having a productive discussion about good database design (and I
guarantee you that maybe over half of the other coders involved will get
educated), rather than having a slanging-match. Approached the wrong way
this particular situation could turn into a furrball.
Don't get me wrong - I don't believe in letting people off easily if they
need an abject lesson. For example, if I saw a senior programmer
perpetrating atrocities with threads or class design I'd think it time
that
they were brought to task for not knowing basics. I've had my ass hauled
over the coals a few times too. But for something like this, where (let's
face it) many (if not most) general-purpose programmers, even senior ones,
aren't necessarily that good at database design, it might be better to
craft
a lesson out of it rather than have an Inquisition...
[ SNIP ]
AHS
|
