More general: When you optimize for one schema of your data, you often de-optimize for other views of the same data. You can try to use views, denormalize, use

More general: When you optimize for one schema of your data, you often de-optimize for other views of the same data. You can try to use views, denormalize, use materialized views, replicate, use document databases, unstructured data, etc., but you always remain in the realm how well the tradeoffs are fit for current and future requirements. You can go with very general approaches, like graph databases, which allow you to retain structure, though at the cost of complexity and less safety. It's still a tradeoff. Schema for graph databases may make sense, but then you need to setup good design and constraints dilligently after all. What is easy to write now, could be difficult to change or read later. What is easy for one developer, could be confusing to others. The grass is always greener on the other side, so the lure is to go in circles over time. This is the bread and butter anyways, as how we use computing always changes. Experts deal in complexity, so others don't have to. But even if we want to, it's hard to escape. Just thinking hard and long about these problems takes time nobody is interested in paying for.