3 ms·
One useful piece of rhetoric is using "schema-on-read" instead of "schemaless". It helps make it clearer that the schemas aren't eliminated by using a "schemale
by shoo 3y ago
One useful piece of rhetoric is using "schema-on-read" instead of "schemaless". It helps make it clearer that the schemas aren't eliminated by using a "schemaless" data store, you're just pushing the responsibility of data validation into all of the data-consuming applications. Shift right!
I think i encountered "schema-on-read" vs "schema-on-write" from the book designing data-intensive applications
- roenxi 3y agoThanks for the tip. Persuasion isn't my forte and I don't think I've ever seen a pro-schema argument win against a let's-make-table-soup team lead. It is so frustrating when people inevitably converge on an obvious schema that they just don't want to let the database know about - or develop the Things table that re-implements database schemas poorly. The old table that is clearly several other tables mashed together. This data is going to be the longest lived and probably most valuable artefact of the company. It is nearly free to put a schema on it, it improves correctness and performance more or less for free. Yet still it isn't possible to get consensus that telling the database the data schema might help. People don't realise how inefficient JSON blobs are either. I swear there must be AWS databases losing a significant fraction of their IO budget to re-parsing what should be column names with every data point read. I can only hope that postgres devs have rolled their eyes and optimised the case where people don't know how to express tables in SQL.
- ludicity 3y agoAuthor here. Many of my readers have suggested I read Kleppmann, but I haven't looked at it yet since there are so many good books to go. I didn't realize this was covered in there, but it has shifted the book to near the top of my list, after some TDD and XP stuff.
- deleted 3y ago[deleted]