3 ms·
Another way of looking at it is that you have a schema whether you like it or not. If I write some code to sum up account balances, it's going to expect a seri
by ben509 8y ago
Another way of looking at it is that you have a schema whether you like it or not.
If I write some code to sum up account balances, it's going to expect a series of account objects, and they need to have some `.balance` field.
And those fields need to be decimals, because addition will choke if they're not.
Your code implicitly defines a schema, and it's utterly rigid because it will crash if the data structure is incorrect.
Or worse.
Imagine if some of the "balances" are actually some irrelevant field that happens to be a number, or some are missing because some of the JSON misspelled the field name and you skipped those records. Now the result you're processing is silently wrong, and who knows how far the corrupt data gets before someone catches it?
All schemas are enforced rigidly because that's how computers work. The difference is whether you want the DBMS to nag you while you're coding, or whether you'd rather be woken in the middle of the night by an angry customer or boss.
- threeseed 8y agoFor many use cases we don't know the schema up front. So it's irrelevant whether it exists or not because we don't know it.
- ben509 8y agoThat's a great point, but I think the real issue there is that typical SQL DBMS's make it very hard to adjust the schema iteratively as you code. After all, if you're writing in a language like Java, you don't know what your classes look like to start with, but coders manage that by adjusting and refactoring them as they work.