The problem I see with this is that the "What's wrong with SQL" is an excellent argument against SQL the language, but not SQL the engine. The optimal solution to that problem seem to be a syntactic skin over an existing SQL engine.
We Can Do Better Than SQL
331–340 of 466 posts
Re: We Can Do Better Than SQL
#332People have tried for decades. Go nuts.
Re: We Can Do Better Than SQL
#333Am 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.
Do you like relational algebra, SQL the language, or both?
To me relational algebra is the beauty queen, and SQL is the "beauty mark" that prevents it from reaching perfection.
Re: We Can Do Better Than SQL
#334Earlier quoted context omitted.
> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…
>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax. WITH statements alleviate some of this issue by allowing you to write subqueries in any order.
Ecto.Query in the Elixir universe seems like it was inspired by linq
Re: We Can Do Better Than SQL
#335No. Having worked with MongoDB for 5+ years now back to PostgreSQL, I do like SQL so much more than a custom query language. I would wish JSON would be better integrated in SQL, it kind of feels like an addon not the core. Otherwise SQL is a fine language. Also I can leverage 20y of SQL.
EdgeDB is built on postgresql and has excellent JSON integration. https://edgedb.com/docs/datamodel/scalars/json#type::std::js...
I wish instead of
SELECT to_json('{"hello": "world"}');
it would be
SELECT {"hello": "world"};
Re: We Can Do Better Than SQL
#336It'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…
A very simple, basic SQL query would be something like "select * from users where foo=bar;"
Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows.
There are far more consistent and beautiful querying languages than SQL: I would point to MongoDB's query language, which is less of a query language and more of a static javascript-interpretable library, but is still far easier to learn and more consistent than SQL. The same query in MongoDB: "db.users.find({ foo: "bar" });". How is this better? It embeds the operation in the statement ("find"); reading it hierarchically follows how the data is stored (Collection > Rows); the filtering operation is the same shape as the data being stored; and it naturally disallows most injection attacks.
Re: We Can Do Better Than SQL
#337The claim can be made that: We can do better than ANYthing.
The counter is: Why hasn't anyone yet?
Re: We Can Do Better Than SQL
#338Earlier quoted context omitted.
>For example in Linq you can chain arbitrary many select/join/where/group by in arbitrary order. In SQL you need nested subqueries to achieve the same which is a much more convoluted syntax. WITH statements alleviate some of this issue by allowing you to write subqueries in any order.
WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.
CTEs do not get cached though, so they are actually quite bad for repetition without also using a temp table.
Re: We Can Do Better Than SQL
#339It'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…
A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…
That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.
Re: We Can Do Better Than SQL
#340It'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…
> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…
I disagree, the relational model is very incongruous with the object model that nearly all LOB applications use. Which is where 99% of the usage issues lie.