3 ms·

Indeed, usually when you have an unstructured data problem.. you just haven't thought about the problem hard enough.

• loopz 5y ago
  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.
• david422 5y ago
  People forget, or don't understand, or don't care about the maintenance. Sure, it's easy to use unstructured data _now_, or in a week. But when the original maintainers have moved on, or not documented how it works, and a year from now when people are making changes, it becomes a slow slog to try to wade through the reality of the data to try to understand how it works and not break anything. Repeat this for every new engineer, for every change that needs to be made, forever. It's a gigantic time sink.