Re: Multiple tables refer to one -To use foreign keys or not?

From: Adriano Varoli Piazza <>
Date: Fri, 30 May 2008 11:05:21 -0700 (PDT)
Message-ID: <>

On May 30, 2:10 pm, Bob Badour <> wrote:
> Adriano Varoli Piazza wrote:
> > On 29 mayo, 22:11, Bob Badour <> wrote:
> >>Gene Wirchenko wrote:
> >>>Adriano Varoli Piazza <> wrote:
> >>>>On 29 mayo, 18:38, Bob Badour <> wrote:
> >>>>>I will cite Date's _Principle of Incoherence_ and ask whether you are
> >>>>>re-inventing EAV, yet again?
> >>>>Reading,
> >>>>but this doesn't look like the same problem at first glance. I'll try
> >>>>to wrap my head around the concept.
> >>>>Though it does seem to be an awful lot of work for this particular
> >>>>task.
> >>>>Thanks for the readup anyway, if it's the right solution, good, and if
> >>>>it's not, I'll avoid reinventing stuff in the future.
> >>>     It is not the right solution.  It is a hideous way to do it.
> >>And I want to make clear I wasn't accusing the OP of anything hideous. I
> >>could not make enough sense of his post to tell what he was doing, and
> >>some of it seemed suggestive of yet another reinvention of EAV. Not
> >>enough to say for sure, though.
> > A simple "Your post is very confusing, please clarify X, Y and Z"
> > would have been better.
> No, actually, it wouldn't have. You might have preferred it, but it
> would have done you a lot more harm than good.

Ok, then this was a better reply than your original one. Though I don't understand how asking me to rephrase my problem (thus rethinking it) would do more harm.

> The only really useful and helpful thing I can say is: You need to learn
> the fundamentals before you start designing databases. And learning the
> fundamentals has nothing to do with learning the SQL language.

Yes, this is clear. I have the impression, though, that learning some of the fundamentals implies a bit of experience in most real-life cases. I could be wrong.

Adriano Received on Fri May 30 2008 - 20:05:21 CEST

Original text of this message