Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 5 down vote favorite

According to Tiobe, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html (not exactly reliable but still)

and just noticing around here.

I see less talk about SQL in general? Has there been a slump in web development that uses databases like Mysql, or Data Warehousing here recently?

Or have alternate solutions like NoSQL/CouchDB/MongoDB started to take over or what? or have I just been missing something?

share|improve this question
4  
SQL databases have been around for centuries and are used nearly everywhere. Even if it's not a growing market, it won't disappear over night. Or shrink into oblivion within the next years. Well, that's my estimation anyway. – delnan Feb 23 '11 at 20:47
3  
Uhm...centuries? – Michael Todd Feb 23 '11 at 20:51
1  
@michael that might have been a slight exxageration ;) – morganpdx Feb 23 '11 at 20:53
1  
Tiobe obviously sucks. C# behind Python? Transact-SQL and PL/SQL behind Logo? COBOL behind D? What is that supposed to mean? – user281377 Feb 23 '11 at 20:53
1  
Yes, the old R'lyeh CMS system. – Sergio Feb 23 '11 at 20:53
show 5 more comments

migrated from stackoverflow.com Feb 23 '11 at 20:46

closed as not constructive by Yannis Rizos♦ Feb 15 '12 at 21:42

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

8 Answers

up vote 10 down vote accepted

There will always be a need for SQL developers. I don't see document based databases replacing Structured databases anytime soon because so many systems depend on them and not all use cases fit well with the alternative.

While it's true that ORMs are really getting more and more usage, some things are just left to be handled at the database end of the stack. Call it protocol, tradition or plain fear - there will always be DBA's demanding things be done on the database end.

share|improve this answer
I agree, ORMs are removing the need to know SQL but anything complex needs to be done in stored procedures (or equivalent) – Richard Feb 23 '11 at 21:02
1  
+1 for the DBA comment, very very true for big corporate. It'll be a loooong time before they don't employ DBA's to look after their databases. – Ozz Feb 24 '11 at 8:35
Never say "always". SQL is a 1980s solution already struggling to meet 21st Century needs. One day I expect we will look back and wonder how we could have let such a crippled, non-relational database language dominate for so long. – sqlvogel Feb 25 '11 at 10:30
up vote 13 down vote

SQL is dying in the same way as C,

i.e. its not

share|improve this answer
3  
I was about to kill you for saying that C is dying... then I noticed you weren't that foolish after all ;) – Anto Feb 23 '11 at 21:01
phew, almost didn't add the i.e. in – beck Feb 23 '11 at 23:12
up vote 5 down vote

Perhaps a reduction in SQL discussion is due to an increase of discussion about ORM technologies. The questions are still there, just being asked as framework questions instead of programming language questions.

share|improve this answer
That's what I've noticed, and coming from a background of data solutions it makes me sad. Especially the banner on the LinqPad site. – StuperUser Feb 23 '11 at 21:58
up vote 5 down vote

Even with the birth of NoSQL/CouchDB/MongoDB, SQL will still be used a lot. There were a huge amount of discussions about that here, but also on forums and blogs, so I will not explain why. SQL will remain.

ORMs, on the other hand, make it easier for small companies using unprofessional staff to develop SQL-based applications without the need to hire a dedicated SQL developer.

In the pastr, they were able to develop applications using a real database only if their in-house software developer(s) already "knew" SQL. Even so, it resulted in less-then-efficient applications, which, after growing a bit, required to use the services of a real SQL developer to find and remove the bottlenecks and transform poor performance queries into something better.

With ORMs, an ordinary software developer has a feel that she can master a database just by querying the objects in the same way she's using business objects. It means that less companies will feel the need to have an SQL developer at the beginning of the project. Worse, when the application will grow, they will still feel that they don't need an SQL developer, since nobody really used SQL during development nor watched what queries were built by the ORM and how efficient they are. Even if somebody know how to use a profiler (not an SQL profiler; an ordinary one), if they find that a bottleneck is a call to a database made by an ORM, they will think there is nothing to do with it, because it's a problem with the ORM and it cannot be solved.

So yes, ORMs can have a negative impact on SQL developers job.

share|improve this answer
I agree, SQL becomes hidden more and more behind layers of abstractions much the same way fewer and fewer people write assembly language any more. This said, same for assembly language, there will always be a need for this skill. That is until a better way is created to represent and interact with large complex datasets, however the math behind SQL was really well thought out so that may take a while. Circumstantial proof of this is displayed in nate c's answer. – Newtopian Feb 24 '11 at 2:19
I won't give you a minus or anything, but this statement "ORMs, on the other hand, make it easier for small companies using unprofessional staff to develop SQL-based applications without the need to hire a dedicated SQL developer." I'd say ORM code can be just as complex to write as SQL code and you can get just as bad systems that do use SQL. It always depends on the developers doing the writing! :-) – Ozz Feb 24 '11 at 8:41
@james: yes, ORM code can be just as complex as SQL. But it gives to an inexperienced non-SQL developer a feel that things are very easy and that she don't have to know how database work. Of course, finally, this makes her write a very bad code which spends hours to make a query which can be made in a few milliseconds if it were written by a professional SQL/ORM developer. – MainMa Feb 24 '11 at 13:33
up vote 1 down vote

A lot of people will say that developers are suppose to/will eventually do all that is needed with regards to SQL or Database development in general, but I disagree. As a developer myself, I have experienced 1st hand the value of someone specializing in DB's and how much time and effort it has saved me. There will alway be a need for SQL, and as long as it's still alive, we gonna need some good DBM's!!

share|improve this answer
up vote 1 down vote

The longer I work in development, the more I use SQL. I've seen many projects try ORM frameworks, only to abandon them in whole or part and move to handcrafted SQL for flexibility, capability, and/or performance that ORM just cannot provide.

share|improve this answer
up vote 0 down vote

google trends thinks not.

nosql 0 sql 1.00 orm 0.01 (sql is in red)

nosql 0 sql 1.00 orm 0.01

share|improve this answer
1  
yes... see answer from MainMa... It will diminish for sure but will not disappear for a long time still. – Newtopian Feb 24 '11 at 2:21
up vote 0 down vote

SQL is essentially broken and (hopefully) isn't likely to remain the model of choice for data management systems in the not-so-distant future. Having said that, Tiobe is probably indicating only the fashionable NOSQL mindshare rather than any fundamental long term trend. None of the alternatives that go under the NOSQL banner really offers a future alternative to SQL for general purpose data management systems.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.