this post was submitted on 04 Oct 2023
74 points (84.9% liked)

Programming

16992 readers
309 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

If you're modeling relational data, it doesn't seem like you can get around using a DB that uses SQL, which to me is the worst: most programmers aren't DB experts and the SQL they output is quite often terrible.

Not to dunk on the lemmy devs, they do a good job, but they themselves know that their SQL is bad. Luckily there are community members who stepped up and are doing a great job at fixing the numerous performance issues and tuning the DB settings, but not everybody has that kind of support, nor time.

Also, the translation step from binary (program) -> text (SQL) -> binary (server), just feels quite wrong. For HTML and CSS, it's fine, but for SQL, where injection is still in the top 10 security risks, is there something better?

Yes, there are ORMs, but some languages don't have them (rust has diesel for example, which still requires you to write SQL) and it would be great to "just" have a DB with a binary protocol that makes it unnecessary to write an ORM.

Does such a thing exist? Is there something better than SQL out there?

you are viewing a single comment's thread
view the rest of the comments
[–] r1veRRR@feddit.de 7 points 11 months ago (4 children)

I'd recommend everyone check out https://prql-lang.org/. It's SQL, but readable and writable in a sane way.

And no, SQL is NOT readable or writable for anything involving more than a single join.

[–] BitSound@lemmy.world 2 points 11 months ago* (last edited 11 months ago)

I'm pretty excited about PRQL. If anything has a shot at replacing SQL, it's something like this (taken from their FAQ):

PRQL is open. It’s not designed for a specific database. PRQL will always be fully open-source. There will never be a commercial product.

There's a long road ahead of it to get serious about replacing SQL. Many places won't touch it until there's an ANSI standard and all that. But something built with those goals in mind actually might just do it.

[–] BehindTheBarrier@programming.dev 1 points 11 months ago* (last edited 11 months ago)

I'm not too much of a fan of the SQL equivalent of SELECT not being at the top. Granted I'm fairly sure there are some arguments for it. Since select is optional there's a higher mental load trying to figure out where and what is actually being returned imo. At least from looking at this for the first time.

On the other hand, i'd kill for f-strings, the top N in group (which is nigh unreadable in SQL), and null handling that doesn't require me to write either COALSECE or NVL too often. The joins were a little less pretty though, I'm quite fond of normal SQL joins since they are very reasonable unless chained beyond the line count your screen can show.

[–] luckystarr@feddit.de 0 points 11 months ago

You can write selects with many joins, as long they are regular and either add a column or reduce the result set. You have to write the joins explicitly though. Just shoving all of the restrictions into the where clause will definitely confuse everybody.

[–] Sigmatics@lemmy.ca 0 points 11 months ago

The main advantage being more concise syntax?