This violates one of my core, learned-the-hard-way, database design constraints: querying of rows should never have to rely on any linear dependence on any othe

This violates one of my core, learned-the-hard-way, database design constraints: querying of rows should never have to rely on any linear dependence on any other row in the same table. If you ever have to do some sort of inner join of a table on itself to bring in the single "next" row to tell you information about the current row, then you are stuffed. Query complexity explodes. Performance takes a nose dive. The end date of a contract is a property of that contract, not any other. Forgetting all other contracts for a moment, what do you need to know about one contract? There should be a straight forward way to query that contract on its own, with a query that represents a tree through tables in the database. It should not become a graph, with the potential for cycles that graphs allow. And I get the business requirements could need no overlaps, but gaps are clearly possible if a customer leaves for a while and then comes back later. Does that person need to then become a new "customer", because you don't allow gaps? And then are your customers' PII only allowed to be registered to a single account? Comcast has been a huge pain in the ass in years past because of moving, gaps, and email address reuse.