Re: Master implied, but needed in design?

In article <mwiikD2oMF9.Cx5@netcom.com>, mwiik@netcom.com (Michael Wiik) wrote: > Pardon me for this basic relational theory question. > > I'm writing an Informix 4GL program allowing edits of "packages" which > contain "order codes". > > Constraints: 1) Each package contains one or more order codes. 2) An order code can only exist once in a package. 3) Different packages can contain the same set of order codes. 4) There is no data to store for a package except the set of order codes. 5) There will never be enough of these for disk space to become a concern. > This was originally designed as a single table, to wit: > create table pkg_orders ( pkgcode char(5), ordercode char(5) ); What you have is a M:M relationship between packages and orders. Normally you would have 3 tables - 1 for package (as in header), 1 for ordercode (description?) and 1 for the relationship between them (which is what you have). Since there is (currently) no date for either the package or order, you are correctly left with the relationship table between them. > 1) Easier coding and maintenance, as plentiful master-detail examples exist. Adding the table when it isn't used adds to coding and maintenance. > 2) A master-detail relationship seems to me closer to the design concept as described above. You have what you need and it is correct. > 3) Inevitably, when additional columns are added to the definition of a package, changing the code to conform will be simplified. No more so than changing it now. When columns are added, add the tables. Douglas Holmes