Re: Master implied, but needed in design?

In comp.databases.theory (<mwiikD2oMF9.Cx5@netcom.com>) Michael Wiik (mwiik@netcom.com) 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) > ); I'd recommend three tables; one for package codes, one for ordercodes and a third that relates packages to order codes. The single table approach has a number of problems, including, but not limited to, these shortcomings: 1. There may be a future need to store more information about packages than which order codes each contains. 2. The single table approach does not address situations like order codes that are not, at some point, included in a package. 3. The table for order codes establishes the set of valid codes for inclusion in any package. 4. Similar to the first point, there may be a need in the future to store more information about order codes than their inclusion in packages. - Robert robert.garvey@sybase.com Sybase, Inc 6475 Christie Ave Emeryville, CA USA 94608-1010 Opinions may be attributed to poster, not necessarily related to Sybase.