February 26, 2008 at 8:50 am
I would love to hear what other DBA's out there think of LINQ to SQL and Entity. What have you noticed in terms of performance? Do you like the approach? Any thing you dislike?
March 3, 2008 at 11:35 am
I'm not a big fan right now. Mostly because it seems to reintroduce a lot of the weaknesses seen in previous attempts at the same thing. It's a fancy way to reintroduce "dynamic SQL" constructs into .NET coding, with all of the crappy SQL and less than optimal code that was there previously.
While it does introduces an abstraction layer of sorts in that it's technically a pre-baked "data access layer" - the way being pushed doesn't seem to add any benefits and is essentially an XML schema "on steroids" with no regards to user security. It's also a bit useless to have that abstraction, since LINQ drivers are ONLY available for SQL Server and non-RDBMS formats (XML/Excel/text files). Oracle is only giving it minimal lip service right now, and DB2 still has a way to go before even an "limited" driver is available.
The performance currently takes a fairly substantial hit. A presenter a few weeks ago was proud to tell me that with the "right tweaks, most LINQ code would perform at 80% of native SQL code". Meaning - LINQ takes at LEAST 20% "off the top" just for the privilege of using it, and in those unfortunate cases where it makes a bad choice (since it builds the underlying SQL calls for itself), it takes quite a bit more.
The biggest flaw IMO though is that it's a tool being marketed in absolutely the wrong way to absolutely the wrong people. It's a tool that could be VERY useful for database-savvy developers - but it's being pushed as a way for developers to "not have to KNOW SQL in order to WRITE SQL". Now if that fact alone isn't a trainwreck just waiting to happen - I just don't know what is.
Fact is - the pre-built code generator isnt' smart enough for all scenarios, and it seems to lead towards taking a giant step BACKWARDS in app dev. Meaning - not keeping your "data code" outside of your "app code".
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 3, 2008 at 11:40 am
Thanks for the info. I feel the same way, and wanted to hear what other DBA's were saying, and any facts they have heard.
I've already heard lots of develpers rave about the idea, and to me it sounds like steps backwards and a real risky train wreck potential. Expecially if the current process for security, and code execution is working well.
March 3, 2008 at 11:47 am
The sad part is - it can be used as a very decent way to create a BusinessObjects - like "universe" for your devs to interact with. That's actually the "right" way to build a LINQ interface - but it makes refactoring the DB (and the manual universe you just built) twice as painful (since you have to manually refactor all of the LINQ objects.)
But - that goes against what they're trying to incentivize (the dynamic "mix and match" stuff with your data), so i don't think this alternative will catch any "play" pretty much anywhere.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 4, 2008 at 7:52 am
I am hoping for massive uptake in the use of LINQ to SQL, especially without using stored procedures. A large part of my consulting business comes from performance tuning work, and since LINQ to SQL has quite a number of performance issues associated with it, I forsee profitable times ahead!! 😎
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 5, 2008 at 1:41 am
Matt: I was reserving my opinion on it till someone had real world facts.
You know how when someone comes up with an idea and it just doesn't feel right but you can't quite vocalize what it is that is wrong? I've always felt this way about LINQ.
You've just proved my doubts - only 80% as good as native - with the right 'hacks'!
Cheers
--Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
March 5, 2008 at 6:56 am
Shaun McGuile (3/5/2008)
You've just proved my doubts - only 80% as good as native - with the right 'hacks'!
Hate to say this but seeing a post on a forum is not proof of ANYTHING! Especially when it is second hand he-said stuff. 🙂
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 5, 2008 at 7:09 am
True. It's not proof of anything. It's also being ramrodded down everyone's throat - so it's coming - like it or not. It's to the point where I'm starting early on how to figure out how to keep a handle on it. Shaped the right way, with TRAINED developers who can understand the pitfalls - it actually has some potential to help. I just wish there were ways for the DBA to be allowed to set what options were or weren't "allowed" (For example - I'd really like to "suppress" the NOLOCK method, e.g. in query.NOLOCK().EXECUTE()).
There's are definite cost in overhead though - how much and whether it's noticeable will be an entirely different topic. That will be the big "it depends". Something taking .0012 seconds versus .001 - probably won't be enough to stop going to LINQ. I am actually playing with it right now - so when I do have some actual metrics - I will bring them back up.
If anything - it's time to start making major improvements to your relationships with your data team.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 5, 2008 at 7:13 am
It the case of a NOLOCK situation do you not already have a company policy on this?;)
Regards,
Shaun
Hiding under a desk from SSIS Implemenation Work :crazy:
March 5, 2008 at 7:15 am
True - but in order to enforce it now - I'm going to have to go review the .NET code as well.:)
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
March 5, 2008 at 7:51 am
I think cache pollution may wind up being one of the biggest issues - especially for those not on 2005 SP2.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
March 6, 2008 at 5:08 pm
I also am not fond of the idea.
Putting the SQL layer in the hands of the entire engineering arm is likely to be dangerous in most shops.
How can you guarantee performance ?
How can you troubleshoot performance?
How do you find the problem query when it's embedded in code ?
How do you fix a perfomance issue that requires SQL Tweaks? Does it require recompiling binaries and redeploying ? (that means a QA Cycle, etc)....
AHHHHHHHHHHHH
this is NOT a good idea
Gregory A Jackson MBA, CSM
March 7, 2008 at 1:46 am
I think there will be lots of RBAR done by programmers due to this, as they think and are trained in procedural programming methods not set based methods.
Hiding under a desk from SSIS Implemenation Work :crazy:
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply