I think in Thom's example he didn't write out the Client table because it's fine as is.  I also think he has better table names, and that helps to think about the relationships between items better.  The table you call Price is what he calls Equipment, and the table you call Equipment is what he calls Equipment Order.

It's probably easiest to think of it in terms of 3 entities, Client, Order, Equipment.  I assume the following relationships exist:
-  A client can have 0 or more orders, and each order only belongs to 1 client
-  An order can have 1 or more equipments on it, and each equipment can be on 0 or more orders
-  Since order and equipment have a many-to-many relationship, there needs to be an intersection table between them