How to deal with a 'self' relationship in SQL? - sql

Question

In our application, we have clients and each client has a list of customers
client table:
id | name
-------------
1 | happy
2 | bashful
customer table:
id | client_id | name
----------------------------------------
50 | 1 | happys first customer
51 | 1 | happys second customer
52 | 2 | bashfuls first customer
Without going into too much detail, each client is going to have a list of prices that apply to them. For simplicity's sake, we'll say we also have a product table with product ids 1,2 and 3, and every customer will have a unique price against each item. So customer 50 will have 3 rows, customer 51 will have 3 rows, and customer 52 will have 3 rows in this price table.
price table:
id | customer_id | product_id |
----------------------------------------
50 | 50 | 1 | 4.99
51 | 50 | 2 | 6.20
52 | 50 | 3 | 8.00
...
Now here's the kicker: each client should also have their own rows on this price table. We'll refer to this client price list as the 'base list', because in the context of the app it's what all the customer prices will be compared against.
There are three immediately obvious solutions to me, but I'm not sure if any of them are right, or which one is optimal:
Solution 1
Add a row into the customer table where the name is something like 'self', so that 'self' can be treated almost like a client
.
Solution 2
Make the price table have two foreign key columns, one with customer_id and one with client_id, and allow customer_id to be null -- if customer_id is null, I know that row is the client row.
.
Solution 3
Have 2 price tables that are basically identical, one to foreign-key into customers and one to foreign-key into clients.

Answer 1

It is a good idea to declare foreign key relationships. No database that I know of supports a conditional foreign key relationships, so that eliminates having one column for both clients and their customers.
You have not specified if customers are unique to clients, so let me assume that they are not.
That suggests that Options 2 and 3 are the most reasonable. There is actually little to separate them. With a single table, you want a check constraint that exactly one of the ids is set -- unless you have customers shared across clients and you are allowing client-specific, customer-specific, and customer-client specific prices.
The more important consideration, I think, is that prices and relationships change over time. You should be thinking about how to incorporate effective and end dates into the data model to capture this information.