views:

331

answers:

13

I do understand SQL querying and syntax because of previous work using ASP.NET web forms and stored procedures, but I would not call myself an "expert" in it.

Since I have been using ASP.NET MVC and LinqToSql it seems that so much of the heavy lifting is done for me and encapsulated away at the SQL end that I'm questioning whether there is any benefit in continuing to top-up my knowledge of SQL queries or whether I'm better off focusing my "learning time" on other things.

Your thoughts?

A: 

This is main reason why I use Linq2SQL, I hate SQL with a passion, and can never remember the silly syntax :)

I only occasionally write simple CRUD statements in Management studio nowadays. It makes me happy!

leppie
Can the downvoters please explain why my comment/opinion is disturbing you so much?
leppie
-1 because of one of two things: either you're advocating not being able to use SQL (which is what it sounds like), or your answer doesn't really address the question. Either way is worth a downvote IMHO.
Adam Robinson
Why would I have an opinion on SQL if I cant use it? I have used it enough to thoroughly dislike it.
leppie
@leppie: The question was "should I keep up my knowledge of SQL?" Your response was basically "I hate SQL," which is either a) not an answer to the question, or b) (more likely) a "no, you don't need to know SQL"
Adam Robinson
You won't miss the 6 rep anyway.
Robert S.
A: 

Its always a good think to learn the underlying language for stuff like Linq To SQL. SQL is pretty much standardized and it will help you understand a new paradigm in programming.

Daniel A. White
+1  A: 

It is still important to learn SQL queries/syntax. The reason is you need to at least understand how Linq to SQL translate to the database behind the scenes.

This will help you when you find problems, for example something not updating correctly. Or a query performance needs to increase.

It is the same that you need to understand what assembly language is and how it eventually becomes machine language. However in all you don't have to be an expert, but at least be able to write in it and understand it.

David Basarab
+5  A: 

In my opinion, knowing SQL is more valuable than any vendor specific technology. There will always be cases when those nice prepackaged frameworks will not be able to solve a particular situation and knowledge of advanced SQL will be required.

Jason Miesionczek
+12  A: 

You should absolutely know SQL and keep your knowledge up-to-date. ORM is designed to ease the pain of doing something tedious that you know how to do, much like a graphing calculator is designed to do something that you can do by hand (and should know how).

The minute you start letting your ORM do things in the database that you don't fully understand is the minute you've lost control over your model.

Adam Robinson
+1 AMEN ! SQL is an absolutely essential skillset for any serious developer. An ORM can NEVER fully replace that.
marc_s
Great statement. SQL is such a required skill for business applications it isn't funny. Also, if you need to write complex reports, you'd better know some advanced SQL tricks.
Min
A: 
  • You may not always be working in .NET.
  • Doesn't hurt to know the underlying concepts.
  • LINQ to SQL is not being maintained anymore in favor of the Entity Framework
Chris Doggett
@Chris Doggett, do you happen to have a link to support that last bullet? I'd like to know more about that.
John M Gant
Read about it here on SO: http://stackoverflow.com/questions/252683/is-linq-to-sql-doa
Chris Doggett
+1  A: 

It is still important to know SQL and the paradigm (set-based) behind it to be able to create efficient SQL statements, even if your using LinqToSql or any other OR/M.

There will always be situations where you will want to write the query in native SQL because it is not possible to write it in LinqToSql / HQL / whatever, or LinqToSql is just not able to generate a performant query for it.

There will always be situations where you will want to execute an ad-hoc query on a database using native sql, etc...

Frederik Gheysels
A: 

Sooner or later you will run into problems that need at leat a working knowledge of SQL to solve. And sooner or later you will run into requirements that are best realised in the DB (whether in SP-s or in triggers or views or whaterver).

juhan_h
+1  A: 

I think LinqToSQL (or other Linq to SQL providers) should not prevent you of knowing SQL.

When your query is not returning what you expect, or when it takes 30 minutes to run on the production database, you'd better be able to understand what LTS has generated, and why it is failing.

I know, it's a rehashed topic, and it might not be applicable to what you do ("small" database that will never hit that kind of problem etc), but it pays not to get too oblivious of abstraction layers sometimes.

The other reason is, Linq does not the whole range of what you can do in SQL, so you might have to resort to writing "raw" SQL, even if the result is materialised as objects.

Denis Troller
A: 

LINQ To SQL will only work with .NET. IF you happen get another job where you are not working with .NET, then you will have to go back to writing Stored Procs.

Knowing SQL will also give you a better understanding of how the server operates as well as possibly making you a better database designer.

Scott Lance
+1  A: 

It depends what you're working on, and from what you said it might make more sense to focus on other areas.

Having said that I find knowing SQL allows the following:

  • The ability to write queries to extract data from systems easily. For adhoc queries, or for checking things.
  • The ability to write complex stored procedures, which allows me to group complex data processing in one place, where it should be, in the database.
  • The ability to fine tune LinqToSql by adding indexes, and understanding the SQL/query plan's it procedures.

Most of these are more of a help on more complex systems, so if you're not working on those it might not be as much of a help.

It may help in your situation to list the technologies which might be of use, and then prioritise them.
In order words make a development plan for yourself, which may encompass more then just learning technical knowledge but allow a more broad focus like design patterns, communication skills and other areas.

Bravax
+1  A: 

SQL is a tool. Linq to SQL is also a tool. Having more tools in your belt is a good thing. It'll give you more perspectives when attacking a problem.

Consider a scenario where you may want to do multiple queries or multiple updates to the db in one operation. If you can write TSQL you can potentially save yourself a lot of roundtrips to the database.

Linus
+1  A: 

I would say you definately need to know your SQL in depth, because you need to know what code your Linq-expression generates and what effects the code will have if you want high performing queries. Sure you might get the job done in most cases, but sometimes there is a huge difference in performance in very subtle difference in Linq-syntax.

I ran into this this morning actually, where I had done .Any(d => d.Id == (...).First().Id) instead of doing where (...).Any(i => i.Id == d.Id). This resulted in the query executing five times slower.

Sometimes you need to analyze the actual Sql-query to realise the mistakes you make.

Runeborg