this post was submitted on 27 Jul 2024
834 points (97.8% liked)
Programmer Humor
19551 readers
1031 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is true if most or all of your data is such. But when you have only a few bits of data here and there, it's still better to use the RDB.
For example, in a surveillance system (think Blue Iris, Zone Minder, or Shinobi) you want to use an RDB, but you're going to have to store JSON data from alerts as well as other objects within the frame when alerts come in. Something like this:
While it's possible to store this in a flat format in a table. The question is why would you want to. Postgres' JSONB datatype will store the data as efficiently as anything else, while also making it queryable. This gives you the advantage of not having to rework the the table structure if you need to expand the type of data points used in the detection software.
It definitely isn't a solution for most things, but it's 100% valid to use.
There's also the consideration that you just want to store JSON data as it's generated by whatever source without translating it in any way. Just store the actual data in it's "raw" form. This allows you to do that also.
Edit: just to add to the example JSON, the other advantage is that it allows a variable number of objects within the array without having to accommodate it in the table. I can't count how many times I've seen tables with "extra1, extra2, extra3, extra4, ...." because they knew there would be extra data at some point, but no idea what it would be.