I like solving problems when programming is the source of trouble, or with programming as the troubleshooting tool. Favorite tools: SQL and .NET. A long history of IT projects in finance and banking.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.