I am not surprised because the problem wasn't correctly defined: > At the database level, they had a "one-to-many" relationship between customers and addresses

I am not surprised because the problem wasn't correctly defined: > At the database level, they had a "one-to-many" relationship between customers and addresses. Which the author goes on to say causes: > That was their first problem. A customer's partner might come into Bob's and order something and if the address was entered correctly it would be flagged as "in use" and we had to use a different address or deliberately enter a typo. But that's not true. The problem being described is not caused or implied by a one-to-many relationship between customers and addresses. The actual problem is that the address table has unique constraints defined in such a way that duplicate addresses are not allowed. So given that the problem was incorrectly defined as one-to-many being the root cause, it makes sense that the proposed solution is many-to-many. Just to be clear, many-to-many in this use case makes a lot of sense and depending on what the schema looks like it may be the best solution. I am just saying that the problem described was not because of "one-to-many". For example I work on a multi-tenant web app and we store emails (which have a similar problem with mailing/billing addresses) with a one-to-many relationship to accounts. We don't have a problem with an e-mail being used in several accounts...because our constraints allow it.