|Subject||RE: [firebird-support] composite primary key|
> current db makes quite a big use of composite primary keys (i.e., PKThis sounds like they have business meaning....RuleId + ActionId
> = RuleId + ActionId, for example). I would prefer not to have such
> composite PK, even not for "relation" tables (when implementing a
> many-to-many relationship).
My vote is always for dissociated PKs. I'd leave them to accrue as per your
client application and set an independent PK in addition.