Programmer Humor

19529 readers

390 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

[email protected]

831

JSON Query Language (programming.dev)

submitted 3 months ago by [email protected] to c/[email protected]

46 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 3 months ago (1 children)

I mean in my case it's for an international company where customers use this structure and the depth can basically be limitless. So trying to find the topmost parent of a child or getting all children and their children anywhere inside this structure becomes a performance bottleneck.

If you have a single level I really don't understand the problem. SQL joins aren't slow at all (as long as you don't do anything stupid, or you start joining a table with a billion entries with another table with a billion entries without filtering it down to a smaller data subset).

[–] [email protected] 1 points 3 months ago* (last edited 3 months ago) (1 children)

My point is that SQL works with and returns data as a flat table, which is ill fitting for most websites, which involve many parent-child object relationships. It requires extra queries to fetch one-to-many relationships and postprocessing of the result set to match the parents to the children.

I'm just sad that in the decades that SQL has been around, there hasn't been anything else to replace it. Most NoSQL databases throw out the good (ACID, transactions, indexes) with the bad.

[–] [email protected] 2 points 3 months ago

I really don't see the issue there, you're only outputting highly specific data to a website, not dumping half the database.

Do you mean your typical CRUD structure? Like having a User object (AuthId, email, name, phone, ..), the user has a Location (Country, zip, street, house number, ..), possibly Roles or Permissions, related data and so on?

SQL handles those like a breeze and doesn't care at all about having to resolve the User object to half a dozen other tables (it's just a 1..1 relation, on 1..n, but with a foreign key on the user id it's all indexed anyway). You also don't just grab all this data, join it and throw it to the website (or rather the enduser API), you map the data to objects again (JSON in the end).

What does it matter there if you fetched the data from a NoSQL document or from a relational database?

The only thing SQL is not good at is if you have constantly changing fields. Then JSON in SQL or NoSQL makes more sense as you work with documents. For example if you offer the option to create user forms and save form entries. The rigid structure of SQL wouldn't work for a dynamic use-case like that.