>...it would be far better to have a table of code per characteristic, so that the combination isn't positional...
Can you please provide a simple example of this?

>This worsens the design, in that cost is not really an element of the combination of codes that go into the table - if you have two red, 2 door, standard transmission cars, they don't need to have the same price.
Actually, I'm only using the automobile metaphor as an example to make things easier to understand (so I though). The actual characteristics are related to direct media publication. Let's assume ALL combination of characteristics are possible.

Costs are actually not defined at COMBINED table level. I'm currently using the COMBINED table as a "master" lookup table only. Under my original auto metaphor, each dealer would select only those combination they keep in stock and assign dealer specific cost. These, "selections" are kept in a separate table (let's say INVENTORY) that actually holds the costs.

>Vehicles have a set of independently varying characteristics; the COMBINED code is a serious mistake, in that you have to define a new COMBINED code if you paint a car or drop its price. Every vehicle has each of these characterisitcs, and the set of characterisitics do not determine the price of the car.
Again, excuse me for trying to use the automobile metaphor.

>You've got to store the independent chartacteristics with the vehicle in any case (otherwise, you can't easily ask for a list of all red cars, or all vans costing $10,000.)
Yes this is what I'm trying to get at! How can I create a flexible database scheme to do this (reflect back to the original data source)?