Will SQL be deprecated?
And about some languages that follow execution order?
There are now alternatives?
An ultimate Relational algebra syntax?
For further actions, you may consider blocking this person and/or reporting abuse
Will SQL be deprecated?
And about some languages that follow execution order?
There are now alternatives?
An ultimate Relational algebra syntax?
For further actions, you may consider blocking this person and/or reporting abuse
Sergey Leschev -
adriens -
Alvison Hunter Arnuero | Front-End Web Developer -
Mark Gilbert -
Once suspended, lorenzotinfena will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, lorenzotinfena will be able to comment and publish posts again.
Once unpublished, all posts by lorenzotinfena will become hidden and only accessible to themselves.
If lorenzotinfena is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Lorenzo Tinfena.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag lorenzotinfena:
Unflagging lorenzotinfena will restore default visibility to their posts.
Top comments (2)
SQL, as a solution for relational data, has a solid mathematical foundation, well-known limits and strengths, and long years of "mental calibration". So, although it is possible to build something new, a candidate has to pass the same journey. Maybe faster, but rather not: we have more developers, more alternatives, more working applications, more data. It's harder now to replace SQL than earlier.
Let's look at NoSQL movement. It was the moment in database history when a concept of something new and better could become real. But it didn't happen. At the end of the day, we have only a next (great, no doubt, but only next) alternative. Even more: not one alternative, but many alternatives.
We have many "old" languages in our programming world, which are going to stay with us for the next decades. SQL is one of them, and it is good, really good. There is a similarity between programming tools and weapons. Now we have new tools, uzis, and glocks, but still, we use knives.
There are frameworks like especially Entity Framework, which can - in long term, and with some changes in origin concept - becomes some kind of SQL replacement. In the context of this idea, SQL would become a kind of assembler. It requires not only changes in EF's project but also in SQL usage. SQL should stay simple enough, focused on "store and search" operations.
But there is a long history of tension between programmers who don't want to know SQL, but are working with relational databases, and SQL developers working hand to hand with SQL engine producers. These SQL folks are existentially and economically interested in keeping SQL more and more powerful for any programming task, not only "store and search". And they produce applications with built-in tool-locks. You can't change the engine without pain and googol of dollars.
So, in final response, will SQL be deprecated? Not soon, not easily, maybe never. There are many alternatives (note: alternatives, not equivalents), and you can use NoSQL languages or ORM-class frameworks in your favorite language. And about an ultimate relational algebra syntax: it is at least hard to do in the commercial (non-academical) area, and probably it will be not even useful. Again, why we started to implement NoSQL engines? Because even the SQL, our current state of the art in "ultimate relational algebra syntax" category is... too ultimate to be useful. As a programmer, I do not need a single tool to work efficiently, like a soldier, for whom any single weapon - glock, uzi, knive, whatever - is not enough. There is (probably) no ultimate weapon, and there is no ultimate relational algebra syntax.
Have a nice day.
I do not think so, because SQL is since the 1970s widely known and there is first of all no interest to change smth about it. Futhermore, it runs and do its job properly, so there is no need for a change. :D