Programming

17424 readers

94 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

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

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

Is there something better than SQL? (programming.dev)

submitted 1 year ago by onlinepersona@programming.dev to c/programming@programming.dev

73 comments fedilink hide all child comments

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

[–] lysdexic@programming.dev 6 points 1 year ago* (last edited 1 year ago) (1 children)

each system has it’s own dialect and quirks

That does not mean that SQL, as specified by one of it's standard versions, is not portable. It just means that some implementations fail to comply with the standard and/or provide their own extensions.

If an implementation fails to comply with the standard, that's a failure on the side of the implementation, not a failure of SQL.

[–] Miaou@jlai.lu 1 points 1 year ago (1 children)

Could also be that the standard is lacking in some areas. I'm not sql expert but I always end up using implementation specific features even for rather simple tasks. Are there really people out there sticking 100% to standard SQL? Hell, the biggest implementations don't even agree on whether table/column names are case sensitive

[–] lysdexic@programming.dev 2 points 1 year ago

Could also be that the standard is lacking in some areas.

I don't think that explains it.

If we're talking about extensions that cover custom features then obviously those aren't supposed to be standardized because they haven't been widely adopted.

If an implementation is missing a feature then that's a shortcoming of that particular implementation, not SQL's.

If an implementation screws up and has non-compliance qwirks, that's a bug in the implementation, not a problem with SQL.

Take SQLite for example. It explicitly does not support static, rigid typing, and claims it's a feature. However, SQL supports static typing and other implementations leverage that for performance and cost gains. Additionally, SQLite also keeps a list with a summary of all the SQL features it purposely does not implement.

SQLite is pretty popular. Does this mean SQL is lacking in any way? Is the SQL standard "lacking" because it supports ALTER TABLE foo ADD CONSTRAINT even though SQLite does not? Or is this a problem caused by an implementation failing to comply with a standard?