Is Linq to SQL any good?

[Michael C]

The thing is that a lot of developers don't want to be bothered with
inline T-SQL or sprocs.

I'd suggest that these developers might want to get a job somewhere else. As
a developer writing database apps known SQL is part of the job and is a
requirement.

That's the bottom line. It's kind of clear here that you have not done any
N-Tier application development that thrives on using a technology such as
Linq-2-SQL

Do a search on something called "Attacking the man, not the arguement"

You ever work with compiled linq queries? You ever work with precompiled
views of the model? What you say is simply not correct. And in todays
database environment such as SQL server, a T-SQL batch is created by the
Linq query and is submitted to SQL server to be executed with a sproc
functionality that is cached on SQL Server.

So, the Linq translation only happens once with a compiled linq query, as
the compiled linq query stays in memory to be executed again, again and
again with no translation needed to T-SQL only parameter substitution on
the tree, because it has been translated onetime to T-SQL and doesn't not
need to be translated over and over.

Um, what are you responding to here? I never said anything about things
being compiled multiple times. What you've written here has no relationship
to anything I mentioned. Hence, I don't know how I could be "simply not
correct"

????????

It's difficult to respond to your confusions when you just post question
marks. What I was saying was the article ignores all the newer features of
sql in sqlserver 2005 where there are other solutions to some of the issues
he raised. For example, the page issue can be solved with the rownumber
function.

 

[Michael C]

I cannot stress how correct this comment is. I think the majority of
programmers who aren't big fans of LINQ-to-SQL are what I call "data
programmers." They understand BOTH their programming language/platform AND
their DBMS. Those of us who are data programmers have difficulty
understanding that a lot of people AREN'T data programmers and don't want
to be bothered with all that low-level SQL stuff. Those folks are the ones
who like things like LINQ-to-SQL, and we data programmers tend to think
they're using a crutch. (They are, and they're happy to have it.)

Low level Jeff? Come on, Joe Celko as difficult a human being as he is, is
always telling us that SQL is *high level*. I certainly wouldn't hire
someone who wanted to avoid writing sql. Working in a business is ALL about
data and if someone doesn't want to know THE data language then they should
go write games.

Michael

 

[Mr. Arnold]

I'd suggest that these developers might want to get a job somewhere else. As
a developer writing database apps known SQL is part of the job and is a
requirement.

How narrow minded you are here very narrow minded to think that one must
know SQL server. All they really need to know is ADO.NET. But most will
know a little bit about SQL server, but it's not a requirement as a
programmer to know the ins and outs of a DBMS. That's the job of the DBA.

And Linq-2-SQL, ADO.NET Entity Framework, nHibernate and many other 3rd
party and in-house written ORMs are being used out there, not so much on
a Windows desktop applications , but rather enterprise level solutions
using n-tier. They are out there. They are not going away, and they are
looking for ORM expertise.

But for the requirement that one must know a DBMS is not the case in
todays environment.

Do a search on something called "Attacking the man, not the arguement"

Is it the truth?

Um, what are you responding to here? I never said anything about things
being compiled multiple times. What you've written here has no relationship
to anything I mentioned. Hence, I don't know how I could be "simply not

This tells me that you know nothing about Linq in regards to Linq
accessing a database and the optimization that can be done.

I must have missed the part about your optimization and your take on how
things will be slowed because Linq has to be translated to T-SQL, when
that's not the case, and optimization can be done with Linq, if one
knows what he or she is doing with Linq-2-SQL or ADO.NET Entity Framework.

correct"

No you're not correct, and you're nowhere in the ballpark.

It's difficult to respond to your confusions when you just post question
marks. What I was saying was the article ignores all the newer features of
sql in sqlserver 2005 where there are other solutions to some of the issues
he raised. For example, the page issue can be solved with the rownumber
function.

The question marks were in response to I didn't know what you were talking.

You have a very narrow minded view of what is happening with ORM(s) it
seems.

 

[Mr. Arnold]

Low level Jeff? Come on, Joe Celko as difficult a human being as he is, is
always telling us that SQL is *high level*. I certainly wouldn't hire
someone who wanted to avoid writing sql. Working in a business is ALL about
data and if someone doesn't want to know THE data language then they should
go write games.

Some don't know the low-level stuff, they don't want to know and they
are programming. Those are the facts.

 

[Mr. Arnold]

Michael C wrote:

<snipped>

One other thing here, I didn't know anything about Oracle on a contract
I worked. They didn't expect for me to know anything about Oracle.
What they did expect from me is that I knew how to do vertical
development from UI/BLL/DAL using ASP.NET.

It was my first encounter with nHibernate, an ORM, that basically built
the DAL and connected to Oracle. When I needed the DBA, she was there,
but I didn't need her that much due to nHibernate.

 

[Michael C]

Some don't know the low-level stuff, they don't want to know

SQL is not low level. It's pretty much the highest level language you can
get. I would considering it to be a far higher level language than C#.

and they are programming. Those are the facts.

I'm guessing these are the same programmers who are responsible for allowing
sql injection into web pages. Luckily I don't work with such programmers

Michael

 

[Michael C]

How narrow minded you are here very narrow minded to think that one must
know SQL server. All they really need to know is ADO.NET. But most will
know a little bit about SQL server, but it's not a requirement as a
programmer to know the ins and outs of a DBMS. That's the job of the DBA.

Hey, I don't think they should know every last detail of sqlserver, as you
said that is the DBAs job. But it is most definately the job of a programmer
(who is writing a database app) to know THE data language at least
reasonably well.

And Linq-2-SQL, ADO.NET Entity Framework, nHibernate and many other 3rd
party and in-house written ORMs are being used out there, not so much on a
Windows desktop applications , but rather enterprise level solutions using
n-tier. They are out there. They are not going away, and they are looking
for ORM expertise.

But for the requirement that one must know a DBMS is not the case in
todays environment.

Really? Any job I've ever interviewed for or seen advertised has required
database knowledge (obviously within the scope of business apps).

Is it the truth?

Yes, that is what you were doing. It's usually done in the absence of a good
arguement.

This tells me that you know nothing about Linq in regards to Linq
accessing a database and the optimization that can be done.

Attacking the man again

I must have missed the part about your optimization and your take on how
things will be slowed because Linq has to be translated to T-SQL, when
that's not the case, and optimization can be done with Linq, if one knows
what he or she is doing with Linq-2-SQL or ADO.NET Entity Framework.

Again, you're just plain inventing things that I said.

No you're not correct, and you're nowhere in the ballpark.

I believe it's you who is out of the ball park. You're responding to things
that I didn't even say.

The question marks were in response to I didn't know what you were
talking.

Thanks for that amazing insight

You have a very narrow minded view of what is happening with ORM(s) it
seems.

Attacking the man again. Generally people do this when someone raises a
good point that makes sense and can't think of anything else to say. You may
as well stick your fingers in your ears and yell "nah nah nah I'm not
listening"

Michael

 

[Mr. Arnold]

SQL is not low level. It's pretty much the highest level language you can
get. I would considering it to be a far higher level language than C#.

That's in your rose colored eyes, and many others don't think a DBMS is
high level.

I'm guessing these are the same programmers who are responsible for allowing
sql injection into web pages. Luckily I don't work with such programmers

That would be someone that knows HTML, Javascript, J-Query, AJAX etc,
etc that's a programmer too.

And that programmer need not know about a DBMS. There are various types
of programmers out there, but does that mean he or she has to know
anything about a DBMS?

And I am not talking about some game software.

 

[Michael C]

That's in your rose colored eyes, and many others don't think a DBMS is
high level.

No, it's just plain fact that a database is high level. I guess I can see
why someone would think otherwise but it is them with the rose glasses.

That would be someone that knows HTML, Javascript, J-Query, AJAX etc, etc
that's a programmer too.

And that programmer need not know about a DBMS. There are various types of
programmers out there, but does that mean he or she has to know anything
about a DBMS?

In a business environment you need to know about database programming. It's
that simple, you have to know it, that's what you are doing, writing
database apps. Certainly someone who didn't know sql would have to be
considered VERY junior.

Are you saying you don't know sql?

Michael

 

[Mr. Arnold]

Hey, I don't think they should know every last detail of sqlserver, as you
said that is the DBAs job. But it is most definately the job of a programmer
(who is writing a database app) to know THE data language at least
reasonably well.

I don't think so not now, because of ORM(s). A java programmer can come
over to .NET and not know one thing about SQL server and still complete
the mission due to an ORM.

Really? Any job I've ever interviewed for or seen advertised has required
database knowledge (obviously within the scope of business apps).

<smile> so it's one shoe fits all here. I didn't know anything about
Oracle, but I was able to complete the contract using nHibernate.

Yes, that is what you were doing. It's usually done in the absence of a good
arguement.

You have no argument here as you can only see black or white -- problems
of a programmer.

Attacking the man again

You don't know, otherwise, you would be putting forth a case.

Again, you're just plain inventing things that I said.

<quote from you>

If we assume we have a complex query to write and we are pretty good at
writing sql, then the sql we write is going to be close to as efficient
as possible. This can only go down when we use linq as it's an extra
translation level and will reduce our ability to optimise the query.


I call them like I see them.


I got you're take on things alright as you can only see black or white
and nothing else.

 

[Mr. Arnold]

No, it's just plain fact that a database is high level. I guess I can see
why someone would think otherwise but it is them with the rose glasses.

I have been working with databases since 1980. A database is not that
high level anymore. It may be the bee's wax with you.

In a business environment you need to know about database programming.

No you don't.

It's
that simple, you have to know it, that's what you are doing, writing
database apps. Certainly someone who didn't know sql would have to be
considered VERY junior.

Werther they are junior or not doesn't that mean they must know t-sql,
and still make a good living.

 

[Michael C]

I have been working with databases since 1980. A database is not that high
level anymore. It may be the bee's wax with you.

Low level is assembler, bit shifting, direct function calls. High level is
when a large amount of work can be done for you with simple commands. SQL is
HIGH HIGH level. It has NOTHING to do with low level.

No you don't.

Yes you do, that is what you are doing, writing database apps. If you don't
know at least something about database you will not be very useful. Even the
non-programmers here write sql, it's much easier to learn for them than C#.
We even have managers writing sql in some cases here when they need ad-hoc
stuff. Yeah I know they probably shouldn't but the fact is they do.

Werther they are junior or not doesn't that mean they must know t-sql, and
still make a good living.

They might be very knowledgeable but not that well suited to DATABASE apps.

 

[Michael C]

I don't think so not now, because of ORM(s). A java programmer can come
over to .NET and not know one thing about SQL server and still complete
the mission due to an ORM.

Maybe so but their ability would be very limited to simple sql. Maybe you
work on simpler apps than me but I couldn't see it as possible to write most
of what I do with linq being translated to sql.

Besides, it really is one thing to add another level because you have a need
for it, and to do it because you are too lazy to learn sql. Obviously if
someone is writing complex linq queries that are getting translated to sql
then they have a need for sql.

You don't know, otherwise, you would be putting forth a case.

Do you understand what "attacking the man" means?

<quote from you>

If we assume we have a complex query to write and we are pretty good at
writing sql, then the sql we write is going to be close to as efficient as
possible. This can only go down when we use linq as it's an extra
translation level and will reduce our ability to optimise the query.

<end quote>

Right. Do you now see how this has nothing to do with your replies?

What I was saying is .... assuming you've just written some extrememly
complex sql for a report, this sql was slow at first but you used all the
tricks you could find to make it fast and you've got to the point of making
it as fast as possible using sql. Then linq can only ever be slower than
that. In some simple cases it might reach the same speed but it can *never*
exceed the speed of a well written sql statement.

I got you're take on things alright as you can only see black or white and
nothing else.

Attacking the man again, when will you ever learn?

 

[Michael C]

Michael, with due respect: You asked the initial question. Now you're
answering it over and over. Not sure at this point if you really
intended the original query as a question. Maybe you should have just
stated: "Linq is no good."

Fair enough. I took offence to Mr Arnold's comments about my ability and he
did manage to suck me into a debate with him. However, in my defence, I was
after *good* reasons to use linq-to-sql. I did acknowledge the good reasons
(compile time checking etc) but I think using it as a method to avoid
learning sql is about as bad a reason as you could get for using it. This
appears to be Mr Arnold's main point.

And incidentally, you seem to be talking mostly about writing
-stand-alone- SQL code while asking about Linq. Two different things.
The correct point of comparison would be embedding SQL source inside
C# code, which is incredibly tedious and prone to error.

When you say stand along sql, do you mean stored procs = stand alone? As for
sql code inside C# I pretty much never do this unless it's a simple "SELECT
* FROM".

Pretty safe
bet that your managers who are generating SQL code are not doing this.

These managers will either run it from management studio or hand it to me to
turn into a report.

Anyway, I thought the link that I posted covered the highlights pretty
well. Charlie Calvert's book "Essential Linq" covers all of this in
depth, and discusses how you'd interface with Sprocs, and where you'd
want to do that. Highly recommended if you really want answers.

http://www.amazon.com/Essential-LINQ-Charlie-Calvert/dp/0321564162

Thanks, I'll have a look.

Michael

 

[Michael C]

IOW, "Linq is no good." You've answered your question.

I was asking about linq-to-sql, not just Linq. I am a big fan of linq and
have been told that I use it too much. But I'm still not convinced about
translating linq to sql. It seems like a difficult enough task optimising
sql without adding another layer.

 

[Michael C]

Michael, with due respect: You asked the initial question. Now you're
answering it over and over. Not sure at this point if you really
intended the original query as a question. Maybe you should have just
stated: "Linq is no good."

I should add I've got an idea now of why people use it, even if I don't
agree

 

[Harlan Messinger]

I was expecting answer somewhere along these lines. The point is there are
good and bad ways to do this. Converting to MSIL is obviously a good way to
do things, converting to assembler and then compiling that would be ok.
Coverting C# to perl would obviously be a bad way to do things and I think
linq to sql is similar. Linq can only ever have less ability than sql.

I don't have any way to address your idiosyncratic notions of
obviousness so I'm not going to bother. I've just read a bunch of your
newest posts and my general sense is that this is really all about you
crowing about how butch you are because you avoid something that you
characterize as a "crutch" in favor of doing the *hard* way, because
you're a *manly* man who *can* do it the hard way and relishes doing so.

 

[Mr. Arnold]

Maybe so but their ability would be very limited to simple sql. Maybe you
work on simpler apps than me but I couldn't see it as possible to write most
of what I do with linq being translated to sql.

Simple T-SQL? The programmer would only need to know the ORM. The
programmer doesn't need to know T-SQL period. And I don't see it getting
any more complicated than working with n-tier applications with physical
boundaries separation.

It seems that you're missing the boat here, as new technology coming
from MS like Silverlight, Windows Presentation Foundation and Windows
Communication Foundation technology are centered around Linq-2-SQL and
ADO.NET Entity Framework, with the ability to use sprocs if needed by
the two technologies. But the emphasis is about querying the data stor
and returning objects and saving those objects to a data stor using
Linq-2-SQL or ADO.NET Entity Framework.

Those are the facts, and they are paying big $$$$$ for the expertise.

Besides, it really is one thing to add another level because you have a need
for it, and to do it because you are too lazy to learn sql. Obviously if
someone is writing complex linq queries that are getting translated to sql
then they have a need for sql.

Yeah, yeah, I worked with SQL Server 6.5, 7.0, 2005, and 2008 with
sprocs and T-SQL coming out of my ears. But in N-tier SOA solutions,
the movement is away from sprocs and all that comes with them. It's
about ORM's and technology like Linq that allows a database to be
quired, and the use of objects that are the result of using such
technology.

Do you understand what "attacking the man" means?


Right. Do you now see how this has nothing to do with your replies?

If someone was just to read what you said, then there is no way to
optimizes a Linq query, but you would be wrong. And my response was
right on the money and addressing you erroneous statement.

What I was saying is .... assuming you've just written some extrememly
complex sql for a report, this sql was slow at first but you used all the
tricks you could find to make it fast and you've got to the point of making
it as fast as possible using sql. Then linq can only ever be slower than
that. In some simple cases it might reach the same speed but it can *never*
exceed the speed of a well written sql statement.

No, you don't write some complicated sproc for a report in the first
place. I have written lots of sprocs for reports. The thing is to keep
it simple. And in todays environment where data is bound to a control,
there are no complicated sprocs and inner and outer joins are frowned upon.

That's were Linq-2-SQL or ADO.NET Entity Framework comes into play with
its ability to query the data stor and bind data to the control by use
of a single Linq query, becuase it returns objects . You don't need
T-SQL, Sproc or none of it.

And with the ability to use WCF RIA services centered around Linq-2-SQL
and ADO.NET Entity Framework CURD can be done with the control using
Linq-2-SQL and ADO.NET Entity Framework without a lick of code needing
to be written, but it is customizable if need be.

Attacking the man again, when will you ever learn?

Will you ever learn that technology is on the move and stands still for
no one. The days of doing T-SQL and sprocs the way you're talking about
are falling to the waste side with developers as new technology is
taking another path more so with Web centric applications.

 

[Mr. Arnold]

Fair enough. I took offence to Mr Arnold's comments about my ability and he
did manage to suck me into a debate with him. However, in my defence, I was
after *good* reasons to use linq-to-sql. I did acknowledge the good reasons
(compile time checking etc) but I think using it as a method to avoid
learning sql is about as bad a reason as you could get for using it. This
appears to be Mr Arnold's main point.

I took offense about your comments period about Linq-2-SQL, when you
only see it from a narrow perspective, which seems to be that of a
Windows desktop developer.

No, it's not my main point that a developer doesn't need to know about
T-SQL. But those are the facts. And no, one doesn't need to know
anything about the database, if one is doing horizontal development at
the Web UI. They don't need to know anything about the database. Those
type of programmers exist, and those are the facts.

 

[Mr. Arnold]

I don't have any way to address your idiosyncratic notions of
obviousness so I'm not going to bother. I've just read a bunch of your
newest posts and my general sense is that this is really all about you
crowing about how butch you are because you avoid something that you
characterize as a "crutch" in favor of doing the *hard* way, because
you're a *manly* man who *can* do it the hard way and relishes doing so.

<smile> I got the same take on his comments too. He wants to roll his
own and saddle up and ride -- the old days. He can have them.