3 ms·

See, schemas do reduce "agility" when you write the code that writes to the DB. Without them, you indeed are "able to churn code very quickly". But then the mom

See, schemas do reduce "agility" when you write the code that writes to the DB. Without them, you indeed are "able to churn code very quickly". But then the moment comes when you also need write the code that would read from the DB what was written into it... oh.

steveBK123 5y ago
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.
nicoburns 5y ago
You can write code almost as quickly (like <5 mins slower) with a schema if you're using any kind of migration tool (which probably maybe requires 1 hour of initial setup). When I'm writing code that requires schema changes, I keep an open migration locally, then I can just unapply and reapply it every time I want to make a change. With MySQL you get quite a few problems when your migration script fails as you can get left in a broken state that you have to sort out manually. But with Postgres schema changes being transactional it's quick and painless.

steveBK123 5y ago

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.

nicoburns 5y ago

You can write code almost as quickly (like <5 mins slower) with a schema if you're using any kind of migration tool (which probably maybe requires 1 hour of initial setup). When I'm writing code that requires schema changes, I keep an open migration locally, then I can just unapply and reapply it every time I want to make a change. With MySQL you get quite a few problems when your migration script fails as you can get left in a broken state that you have to sort out manually. But with Postgres schema changes being transactional it's quick and painless.