Re:SQLite 2022 Recap
by mulmboy on Sunday January 01, 2023 @04:09PM
(#34210915)
As a counterpoint I find that nutting out the schema upfront is an incredibly helpful process to define the functionality of the app. Once you have a strict schema that models the application well nearly everything else just falls into place. Strong foundation
[ Parent
| on HN ]
Re:SQLite 2022 Recap
by HelloNurse on Sunday January 01, 2023 @05:08PM
(#34211555)
With JSON blobs in simple tables a very large part of designing a database schema becomes designing a JSON schema, with different opportunities to make mistakes but (potentially) the same strictness.
How do you enforce the JSON schema?
In the application layer
Re:SQLite 2022 Recap
by breeze1990 on Sunday January 01, 2023 @06:50PM
(#34212493)
define schema with data class and you have tools like protobuf/thrift. And I find it really unnecessary to map every attribute to a SQL column.
Re:SQLite 2022 Recap
by HelloNurse on Monday January 02, 2023 @09:07AM
(#34217935)
We are talking about the internal database of some application: its schema is something that should be designed well, not enforced defensively like a schema for validating undependable inputs.
Nutting?
Thinking. British English idiom. Using your nut - your head.
Tends to mean "ejaculating" in American English, for the record.
What's the difference?
Re:SQLite 2022 Recap
by Rebelgecko on Monday January 02, 2023 @01:14AM
(#34214919)
Re:SQLite 2022 Recap
by freedomben on Sunday January 01, 2023 @06:47PM
(#34212462)
I worked at a startup who did the whole "every table schema is "id, data" where data is a JSON blob with all the data." I loved it at first. For initial development, it felt so freeing and so productive.
Then one of the devs left and I inherited his code, and started to realize exactly how much the rigid schema helps make an app more robust and more maintainable. I will never, ever take that shortcut again. The production outages/downtime caused by database issues that never should have been an issue in the first place (like a corner case row that missing data? Spreading rampant defensive nil checks out across every function that checks any field of a record since any at any time might be inconsistent or nil) contributed to killing the company by pissing off customers.
Elixir/Phoenix does help a lot though because I still treat most rows like JSON objects, but under the hood it's a normal rigid postgres schema. Best of both worlds IMHO.