Circular database relationships. Good, Bad, Exceptions?

Question

I have been putting off developing this part of my app for sometime purely because I want to do this in a circular way but get the feeling its a bad idea from what I remember my lecturers telling me back in school.

I have a design for an order system, ignoring the everything that doesn't pertain to this example I'm left with:

• CreditCard
• Customer
• Order

I want it so that,

• Customers can have credit cards (0-n)
• Customers have orders (1-n)
• Orders have one customer(1-1)
• Orders have one credit card(1-1)
• Credit cards can have one customer(1-1) (unique ids so we can ignore uniqueness of cc number, husband/wife may share cc instances ect)

Basically the last part is where the issue shows up, sometimes credit cards are declined and they wish to use a different one, this needs to update which their 'current' card is but this can only change the current card used for that order, not the other orders the customer may have on disk.

Effectively this creates a circular design between the three tables.

Possible solutions: Either

Create the circular design, give references:

• cc ref to order,
• customer ref to cc
• customer ref to order

or

• customer ref to cc
• customer ref to order
• create new table that references all three table ids and put unique on the order so that only one cc may be current to that order at any time

Essentially both model the same design but translate differently, I am liking the latter option best at this point in time because it seems less circular and more central. (If that even makes sense)

My questions are,

• What if any are the pros and cons of each?
• What is the pitfalls of circular relationships/dependancies?
• Is this a valid exception to the rule?
• Is there any reason I should pick the former over the latter?

Thanks and let me know if there is anything you need clarified/explained.

--Update/Edit--

I have noticed an error in the requirements I stated. Basically dropped the ball when trying to simplify things for SO. There is another table there for Payments which adds another layer. The catch, Orders can have multiple payments, with the possibility of using different credit cards. (if you really want to know even other forms of payment).

Stating this here because I think the underlying issue is still the same and this only really adds another layer of complexity.

Answer 1

A customer can have 0 or more credit cards associated, but the association is dynamic - it can come and go. And as you point out a credit card can be associated with more than one customer. So this ends up being an n:m table, maybe with a flag column for "active".

An order has a static relationship to 0 or 1 credit card, and after a sale is complete, you can't mess with the cc value, no matter what happens to the relationship between the cc and the customer. The order table should independently store all the associated info about the cc at the time of the sale. There's no reason to associate the sale with any other credit card column in any other table (which might change - but it wouldn't affect the sale).