"Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
news:QkT7k.881$yg7.713@[EMAIL PROTECTED]
> "David Cressey" <cressey73@[EMAIL PROTECTED]
> wrote in message
> news:_dO7k.7468$qb7.996@[EMAIL PROTECTED]
> >
> > "Arved Sandstrom" <asandstrom@[EMAIL PROTECTED]
> wrote in message
> > news:Q667k.416$yg7.75@[EMAIL PROTECTED]
> >> "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.
> >>
> > Some of us learned database design before we began designing
databases.
>
> Most of us learn by doing, and it's during that process that you make
> mistakes. You're not seriously suggesting you've never made any?
>
Of course not. But the OTLT mistake is such a fundamental one that is can
be avoided by someone who has learned database design before designing
databases. You can, of course, design a database any way you like. But
many of those ways are anti-patterns. Most of the people who make that
mistake in real production databases are learning database design by sheer
trial and error.
There's a long distance between never making any mistakes and not learning
anything before diving in.
> AHS
>
>
|
