Say I have the following table:

```
TABLE: product
============================================================
| product_id | name         | invoice_price | msrp         |
------------------------------------------------------------
| 1          | Widget 1     | 10.00         | 15.00        |
------------------------------------------------------------
| 2          | Widget 2     | 8.00          | 12.00        |
------------------------------------------------------------

```

In this model, `product_id` is the PK and is referenced by a number of other tables.

I have a requirement that each row be unique. In the example about, a row is defined to be the `name`, `invoice_price`, and `msrp` columns. (Different tables may have varying definitions of which columns define a "row".)

QUESTIONS:

1. In the example above, should I make `name`, `invoice_price`, and `msrp` a composite key to guarantee uniqueness of each row?
2. If the answer to #1 is "yes", this would mean that the current PK, `product_id`, would not be defined as a key; rather, it would be just an auto-incrementing column. Would that be enough for other tables to use to create relationships to specific rows in the `product` table?

Note that in some cases, the table may have 10 or more columns that need to be unique. That'll be a lot of columns defining a composite key! Is that a bad thing?

I'm trying to decide if I should try to enforce such uniqueness in the database tier or the application tier. I feel I should do this in the database level, but I am concerned that there may be unintended side effects of using a non-key as a FK or having so many columns define a composite key.