Subject | Re: Foriegn keys as Composite Primary Key |
---|---|
Author | women_lover_best |
Post date | 2005-07-17T03:40:39Z |
Hi Adam thanks a bunch..
could you please also give some more of your good practices for
Database design,and Firebird related..
thks
vishal
PS:Unfortunately someone hijacked your thread, but
I saw your question...what yu mean by this statement?
could you please also give some more of your good practices for
Database design,and Firebird related..
thks
vishal
PS:Unfortunately someone hijacked your thread, but
I saw your question...what yu mean by this statement?
--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:
> --- In firebird-support@yahoogroups.com, "women_lover_best"
> <talbronstien@g...> wrote:
> > Hi,
> > I have a table with 2 foriegn keys..and We want to make them as
> > composite primary key..(f1 + f2)..is it possible in FB?if yes,is
it a
> > good practice? Performance wise?
> > thanks
>
> Hi Women Lover Best (if you say so),
>
> Hmmm, with a yahoo name like that you may want to sign your name at
> the end of your post. Unfortunately someone hijacked your thread,
but
> I saw your question.
>
> Can you do it, you sure can, as long as the fields are declared as
not
> null, there is no technical problem in doing it.
>
> I would recommend against it though. We have one remaining table
that
> has a composite primary key. The downside is that we need to use
> pretty verbose triggers to define the foreign key relationships to
> other tables. It is a throw back to our paradox db history and it
will
> probably be there for a while yet because it would require me to
spend
> time I don't have for little commercial gain, but given the choice
to
> design that table again it would get an ID field in a blink.
>
> So what I would recommend you do is add an ID column to the table.
It
> is normal for a table to have multiple candidate keys, but just
> because a particular set of fields is a candidate key does not mean
it
> is a sensible way to do it. I would also discourage using a
candidate
> key defined by a customer as a PK, instead I prefer to generate a
> unique number that has no real world meaning to the customer. This
> means you do not have to cascade updates etc, because they never
care
> about changing its value.
>
> Adam