121–130 of 466 posts
Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.
Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.
Then the language is blamed for not performing well or yielding different results than expected.
Some points in this article are valid but I think the main issue is the general notion sql would be like javascript or c#. It is not, it is very different and needs a deep understanding, including the works of the underlying dbms, to perform well.
I guess i'm just not a fan of throwing new languages and tools at problems we identify, which seems to be a trend nowadays.
Would be nice, but bazillions of lines of SQL at the core of almost every business system make this as likely as “We can do better than five fingers.” The article does nicely illustrate many of the well-known shortcomings of SQL. Chris Date and Hugh Darwen unsuccessfully tried to fix SQL with Tutorial D. Never heard of it? Exactly.
Earlier quoted context omitted.
It's 2020 not 1995. There are already lots of good, production-ready SQL alternatives out there. There's full-fledged businesses that have zero lines of SQL.
I would like to hear of one such business. Can you give an example?
It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…
Selecting columns before tables always felt weird to me. Doesn't it make more sense if you had a graphical view this way? (imagine boxes around the below items where you can drag lines to make connections between tables/inputs)
USERS
--user_id-- [data processing] => ...
GROUPS
SELECT * ,groups.* from users INNER JOIN groups ON users.user_id = groups.user_id
SQL is so messy and full of details that can be much better represented via dataflow diagrams.
It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…
I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.
Aside from DDL (which I'm not sure how you would do without distinguishing between base relvars [tables], derived relvars [views], and other classes of relations), SQL doesn't particularly treat different kinds of relation differently beyond what is minimally necessary (you can't write, via insert or update, to a relation that isn't a relvar, for instance.)
SQL is very hard to learn properly, with all of its gotchas and inconsistencies. There are running jokes for noobs truncating their tables due to forgetting a where clause. I’ve seen junior devs crying in tears and throwing their mice just because they needed to debug / optimise a complex query.
The mare existence of all the ORMs is a testament that people would opt to write (or use) insanely complex pieces of software just so they don’t have to deal with the lack of composition and ease of use.
All of those look to me as signs that something wrong with the core itself. We could do better.
If we settled for good enough in all cases we wouldn’t have Go or Rust, React or Postgres. In fact every software that we have is a product of someone thinking “this is hard/wasteful/unexpressive/etc, lets write an alternative”, SQL included.
This alternative looks quite promising. We can wait to see how they can handle the edge cases, but the core looks a lot simpler to deal with than regular SQL.
It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…
I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.