Subject | Re: [ib-support] OT? Surrogate Keys |
---|---|
Author | Brad Pepers |
Post date | 2002-01-04T00:07:27Z |
On Thursday 03 January 2002 03:39 pm, sugi wrote:
for the data. I don't use a surrogate key for the ORDER_DETAIL table since I
consider that data part of the ORDER object and the ORDER_DETAIL table is
just a way to convert multi-value (vector or array) type object data into
relational tables.
Note that if you need to retain the sequence in ORDER_DETAIL you will need
both an ORDER_ID and an ORDER_LineSeq anyways. If you change to surrogate
keys in ORDER_DETAIL and remove ORDER_LineSeq then there is no way to know
the original ordering of the detail lines. So if you have to have it anyway
and that combined with the ORDER_ID has to be unique, I think its fine to
make the primary key of ORDER_DETAIL be ORDER_ID,ORDER_LineSeq.
--
Brad Pepers
brad@...
> Dear All,I have tables like the ORDER table you mentioned and I'm using surrogate keys
>
> This question popped out after reading several articles on the
> merits of using surrogate keys in relational databases. My
> apologies since this is not an interbase-specific issue.
for the data. I don't use a surrogate key for the ORDER_DETAIL table since I
consider that data part of the ORDER object and the ORDER_DETAIL table is
just a way to convert multi-value (vector or array) type object data into
relational tables.
Note that if you need to retain the sequence in ORDER_DETAIL you will need
both an ORDER_ID and an ORDER_LineSeq anyways. If you change to surrogate
keys in ORDER_DETAIL and remove ORDER_LineSeq then there is no way to know
the original ordering of the detail lines. So if you have to have it anyway
and that combined with the ORDER_ID has to be unique, I think its fine to
make the primary key of ORDER_DETAIL be ORDER_ID,ORDER_LineSeq.
--
Brad Pepers
brad@...