While digging into this stock issue I ran across some database design issues that are really going to cause big problems with options, skus, stock, etc.

The Basic Problem:
The uc_product table assumes from the get go that there is a one-to-one relationship of nid -> cost, nid -> price, nid -> sku.

This causes data duplication. For example, there is two different tables that hold model information for a particular nid. The uc_product table and the uc_product_adjustment table both have a field for model. This causes problems with unique skus and which skus are mapped to which nodes.

The Hurdle
How do you accommodate products that don't have options at the same time products that do?

The Solution
I believe the solution lies in the uc_pruduct_adjustments table. It uses nid and combination as the primary key. The combination is just the serialized array of the options that product has. By moving a good chunk of the fields from uc_products to uc_product_adjustments you solve the one-to-one relationship problem.

For products that do not have any options, they just get an empty serialized array inserted as the combination (i.e. a:0:{} ).

The Benefits
Stock, sku, price, cost can now be tracked on a granular level for options as well as just regular products with no options. No duplicate SKUs. Easier for other modules to connect into the complex options without writing head spinning queries.

Yes, this is a big change, affecting probably a lot of the current UC modules in one way or another. It is necessary though for UC to scale and have granular control of products and product options.

I've attached a DB flow chart of sorts, it just helps for me to get the visual relationship between tables / fields.