>What you have is a many-to-many relationship. Each package can have many items and each item can be in many packages. You should probably create two tables to keep track of the packages. One would be a package header table and one a package detail table. Package header would have a package ID, package description, package price, and any other fields that are specific to the package. The detail table would have one record for each item in the package. It would contain the package ID and the item ID.

One easier solution is to have just a table of packages, with the fields you described, and if (and only if) each item goes only once into a package (no need to remember the quantity), you can have a memo with a list of items (i.e. their PKs in string form, delimited). You may actually have some more sophisticated scheme about this memo, but that's the general idea: a package is something from a different table, which keeps a set of PKs of the items table. You can do this in a detail table, instead.

>Alternatively, you might want to use the item table for the package header records. So you could have an item called "Package 1" that was made up of four items. You would add a record to the item table with "Package 1" as the description. Then, the package detail table would have one record for each item in the package. Each record would have the item ID of the package record and the item ID of one of the items contained in that package. You'll probably also need a field in the item table to indicate that an item is actually a package.
>
>It's a bit complex, but it gives you full flexibility to set up any number of packages each with any number of items.

It's more complex - you have to take care of the recursion. I've done that a couple of times (once for an assembly line, and once for a restaurant), where I had to allow some recursion. Each item can be a simple item or a package. Each package consists of one or more items which may be simple items or packages. No package should have itself as a component. The limit of recursion with FPD came close to 8 levels, but only because it took 3 procedure call levels to display the next level, so at 8 I bumped into "do nesting too deep". Anyway, the most complicated thing I've heard of, an ocean liner, has 11 levels at maximum.

The scheme in this case is a table of items and packages (actually a lookup table) and a composition table for packages. The composition table has a two foreign keys, both pointing to the first table; one is the package key, and the other is the component key. Each record has the quantity of the component (in case of the restaurant, I also kept it as a quotient with both denominator and denumerator, because most restaurant recipies are calculated for 6 persons, and I wouldn't like to have trouble with the 0.01 of cans of caviar accumulating over the year... this practice made nice rounded dishes).