My suggestion is to abstract several of the columns in the uc_product table into another table that will allow for a one-to-many relationship. You don't need to have options, but it's there when you do need options.

For example

uc_products
---------------
vid
nid
shippable
...

uc_product_adjustments
---------------
nid,
combination,
cost,
price
list_price,
model,
weight
...

The combination field would store the attributes (if there are none, then you can just store an empty array). The model field could be forced to be unique so duplicates would not be allowed in the system.

Now to get the cost of a product with or without attributes "Select nid,combination,cost from uc_pruduct_adjustments where nid = %d"... if there are no attributes you get one cost, if there are attributes you get several.

The summary of what I am suggesting is that in it's current state, the uc_product table isn't set up to handle attributes very gracefully.

Here is one way to illustrate.
In an UC installation, enable stock and attribute modules.
Create two products, give at least one of them attributes and change the 'Alternate SKU' on the Adjustments page (e.g. 555 and 777).

Now on another product go to the Edit > Product , change the sku to 555.

Now when you go to the Stock stub and change the Stock of SKU 555, it will change on both products.

Changes need to be made to the uc_product table to allow for better attribute support.