Helen,

> >if I'm not mistaken, this is the "classic" (maybe obsolete) way of
> >structuring master/detail relationships. It may not be desirable for
> >performance and/or strictly firebird-related reasons, but from a design
> >point of view I don't see it as bizarre as you do.
>
> It's nothing to do with "Firebird reasons" and it's "theoretical", rather than "classic".

Ok, it's theoretical. But it still isn't bizarre. ;-)

>I would call it the "file-based" way of structuring m/d - it's theoretically correct for a database like Paradox, which uses cumulative keys to form nested relationships, i.e. it doesn't use foreign keys natively.
>
> I'm not saying this interleaved approach *breaks* anything, although (without trying it) I suspect it could get in the way of cascades. But it's bizarre, because the detail structure doesn't *need* a composite key and, since the WONO column defines the foreign key, it's redundant as part of the primary key.

You're part of the new age undoubtedly. But please leave Paradox and
Borland examples out: this way of structuring relationships is just what
Codd used to say a decade ago or so. Borland folks learnt their SQL
basics a little earlier than me and you, and they just didn't update the
MastApp sample to reflect the new views on things. M/D relationships
used to be that way, before surrogate keys took over.

> Sometimes I think people do this because they follow Borland's example in the MastSQL sample database. That database is a dreadful model. It is a straight imitation of the Paradox sample, which commends it very little - it's not even a good Paradox design. But that's where those complex keys came from. [[ Note also the lack of generators and the use of numerics for primary keys in those tables which have simplex PKs... ]]

A classic relational design, in fact.

> Break the shackles and clear out redundant garbage, I say.

A modern relational design, in fact.
Ciao
--
____
_/\/ando