Hacker News new | past | comments | ask | show | jobs | submit login

Typical use case: There are a number of required fields that your app won't work without. Those should be columns, probably non-nullable columns.

Then there're a bunch of optional fields. Traditionally, a number of nullable cols would be created. But they're ultimately messy (need to null check every accesses) and unneeded since you can replace them with a single json item. Keys are always optional, so you always need to check for presence or absence, and modern dbs support json natively in many clauses.




Fields are messy because you have to check for nulls, yet JSON keys aren't messy because you have to check for nulls?


All json keys are optional, so you ALWAYS need to check for their presence or absence. Mess exists when some key is nullable and some isn't. Checking for nullability on a key that can never be null isn't extremely elegant.


Why is that a mess? I don't see the difference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: