Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Entity Framework - Adhoc queries... Expand / Collapse
Author
Message
Posted Wednesday, February 25, 2009 4:05 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, July 24, 2014 9:35 AM
Points: 3,052, Visits: 780
Are any of ya'll using the Entity Framework to develop? I am told that it generates the SQL statements.

I am concerned that having adhoc queries in an Enterprise system, and not using Stored Procedures, is going to create performance problems, AdHoc query cache and bbad sql statements.

God Bless,
ThomasLL


Thomas LeBlanc, MCITP DBA 2005, 2008 & MCDBA 2000
http://thesmilingdba.blogspot.com/
Post #664684
Posted Wednesday, February 25, 2009 9:41 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, May 29, 2014 9:29 AM
Points: 214, Visits: 647
Yeah we're using it. I say "we", they are; the movement to a complete n-tier thanks to OOP programming via vb.net and c# has led to a complete removal of business logic in the database. Now with NHibernate and EF, the trend is starting to remove stored procedures altogether! wth?

I don't like it but we'll have to live with it, since that's what Microsoft is pushing these days. Not only does EF gen sql statements, it gen's a bunch of them to get what a simple SP could have gotten. And yes, you have to give db_datareader (and/or db_datawriter) to the login making the database calls. Moreover, the small, short, little queries that it calls - based on underlying object/impedance matching - are not complex. Therefore it has to do several of them in order to get, again, where a SP could have gotten. Go look at profiler the next time a middle-tier guy fires up a web page. Additionally, it is not capable of using the cool stuff available now in SQL 2005/2008, such as MERGE, CTE, etc. In order to get that you have to create stored procedures and manually map the attributes to EF to leverage that stuff. Finally, in order to keep a connection I have seen it wrap a SELECT statement inside of a transaction. Dumb.

So, having said all of that, seriously, I can't say yay or nay; i'm a consultant, and some clients will use, and some will not. If I had my preference though...





Lee Everest

Post #664766
Posted Thursday, February 26, 2009 7:31 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Thursday, July 24, 2014 9:07 AM
Points: 11,157, Visits: 12,899
I have not used EF yet, but have done a little with Linq to SQL which is somewhat similar, although not as robust. One of the issues with Linq to SQL is that it passes string parameters using their length so that Select * from person where first_name = 'Bob' and Select * From person where first_name = 'Steve' generate 2 query plans because it parameterizes the call and sends a varchar(3) parameter the first time and varchar(5) the second time and it may also be nvarchar so if your column is varchar you have an implicit conversion taking place as well.




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #665004
Posted Thursday, February 26, 2009 8:40 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 5:53 PM
Points: 33,063, Visits: 15,179
I haven't used it, but I've seen a bunch of presentations and I talked with the developers who built LINQ last year.

They realize they're in a 1.0 release, but they've tried to structure the SQL statements they submit to perform well. Lots of workloads from different applications were used to model what they do and for many of the queries, relatively few (inner) joins, their SQL performs well.

I think it can be good or bad, and you should proceed carefully. Run some small pilots, build things two ways, see which one might work better.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #665070
Posted Thursday, February 26, 2009 7:24 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Thursday, July 24, 2014 9:35 AM
Points: 3,052, Visits: 780
Thanks for everybody's input...

It would be nice to hear from some people using it in an enterprise system with 300+ GB databases and 2500-3000 current users on 4-way Quad core machines.

We already have to use MAXDOP=1 on some SPs now because of CXPACKETS. Also, if there is a performance issue, the DBA can make an emergency change to a SP, not .net code.

God Bless,
ThomasLL


Thomas LeBlanc, MCITP DBA 2005, 2008 & MCDBA 2000
http://thesmilingdba.blogspot.com/
Post #665452
Posted Tuesday, May 4, 2010 4:27 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, May 29, 2014 12:39 PM
Points: 110, Visits: 495
I agree with what you are all saying.

We are currently debating this here as well....

it's a tradeoff...

Engineering\Coding Vs DBA state of mind and maintainability

I'm stickin to my guns here and trying to stick to SPROC usage.


Gregory A Jackson MBA, CSM
Post #915726
Posted Tuesday, May 4, 2010 5:38 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 5:47 PM
Points: 1,781, Visits: 5,666
I have minimal experience of EF in one project, and it works just fine,
although it is not being subjected to that much workload.

I would point out though, you can use stored procs within EF for Insert/Update/Delete
operations on Entities.


MM


  • MMGrid Addin
  • MMNose Addin


  • Forum Etiquette: How to post Reporting Services problems
  • Forum Etiquette: How to post data/code on a forum to get the best help - by Jeff Moden
  • How to Post Performance Problems - by Gail Shaw

  • Post #915744
    Posted Wednesday, July 9, 2014 7:31 AM
    Forum Newbie

    Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

    Group: General Forum Members
    Last Login: Monday, July 14, 2014 7:38 PM
    Points: 8, Visits: 45
    I am very interested in a definitive answer here... In a shop like mine where they don't want any stored procs to be used at all, and where they believe that having an in-house DBA is a waste of money (I'm not even kidding), how does one make a convincing argument for stored procs? They are .NET developers who know a bit of SQL; I am a SQL developer and former DBA who was hired to do .NET. I can tell them all of the advantages of stored procs -- protection against SQL injection, greater speed if well-written, quicker deployment -- but I don't know enough about Entity Framework to be able to give them the down sides in a confident way when comparing Entity Framework (with direct mapping) to stored procs...
    Post #1590734
    Posted Wednesday, July 9, 2014 7:47 AM


    SSChampion

    SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

    Group: General Forum Members
    Last Login: Thursday, July 24, 2014 9:07 AM
    Points: 11,157, Visits: 12,899
    mortonsoft (7/9/2014)
    I am very interested in a definitive answer here... In a shop like mine where they don't want any stored procs to be used at all, and where they believe that having an in-house DBA is a waste of money (I'm not even kidding), how does one make a convincing argument for stored procs? They are .NET developers who know a bit of SQL; I am a SQL developer and former DBA who was hired to do .NET. I can tell them all of the advantages of stored procs -- protection against SQL injection, greater speed if well-written, quicker deployment -- but I don't know enough about Entity Framework to be able to give them the down sides in a confident way when comparing Entity Framework (with direct mapping) to stored procs...


    This is a very old thread and there have been many positive changes to EF since this thread was active. For example, in my previous post I said:



    I have not used EF yet, but have done a little with Linq to SQL which is somewhat similar, although not as robust. One of the issues with Linq to SQL is that it passes string parameters using their length so that Select * from person where first_name = 'Bob' and Select * From person where first_name = 'Steve' generate 2 query plans because it parameterizes the call and sends a varchar(3) parameter the first time and varchar(5) the second time and it may also be nvarchar so if your column is varchar you have an implicit conversion taking place as well.


    This is no longer true. The last time I looked it sent string parameters as either varchar(8000) or nvarchar(4000) which means that cached plans can be re-used.

    A few concerns I would still have would be:

    1. Scaling - ORM tools still aren't very good at complex SQL (multiple joins, outer joins, etc...) so you need to evaluate every query that EF is sending and be ready to replace "bad" queries with stored procedures.
    2. Tight coupling - if you really want to take full advantage of EF or any other ORM toll it means that you are tightly coupling the data access layer to your database. That means you are stuck with a specific database design until you can change the application as well. Whereas a design that provides an "API" to the database via views/functions/procedures allows you to change the underlying schema of the database as long as your API presents the same shape data to the application.
    3. Tuning - if there is a poorly performing query there is little you can do to tune it. The SQL is generated so, AFAIK, you can't provide hints (OPTION (RECOMPILE) to help with "bad" parameter sniffing) or re-shape it to get a different plan.

    ORM tools like EF can be great at simple CRUD and simplify those pieces, but there is a cost down the line. Most places I've worked have been willing to put off the cost to later to deliver quickly. It hasn't always work out the best, but it can be hard to convince management to wait a bit to save time later.





    Jack Corbett

    Applications Developer

    Don't let the good be the enemy of the best. -- Paul Fleming

    Check out these links on how to get faster and more accurate answers:
    Forum Etiquette: How to post data/code on a forum to get the best help
    Need an Answer? Actually, No ... You Need a Question
    How to Post Performance Problems
    Crosstabs and Pivots or How to turn rows into columns Part 1
    Crosstabs and Pivots or How to turn rows into columns Part 2
    Post #1590747
    Posted Wednesday, July 9, 2014 8:02 AM


    SSC-Forever

    SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

    Group: General Forum Members
    Last Login: Today @ 3:14 AM
    Points: 42,460, Visits: 35,520
    Jack Corbett (7/9/2014)

    1. Scaling - ORM tools still aren't very good at complex SQL (multiple joins, outer joins, etc...) so you need to evaluate every query that EF is sending and be ready to replace "bad" queries with stored procedures.
    2. Tight coupling - if you really want to take full advantage of EF or any other ORM toll it means that you are tightly coupling the data access layer to your database. That means you are stuck with a specific database design until you can change the application as well. Whereas a design that provides an "API" to the database via views/functions/procedures allows you to change the underlying schema of the database as long as your API presents the same shape data to the application.
    3. Tuning - if there is a poorly performing query there is little you can do to tune it. The SQL is generated so, AFAIK, you can't provide hints (OPTION (RECOMPILE) to help with "bad" parameter sniffing) or re-shape it to get a different plan.


    Agreed on all points. I'm busy tuning a system which uses EF and thousand line long SQL statements are the norm, queries which fetch every column from the table, queries which fetch every row from multiple tables in a set of UNIONS, etc. Half the queries all I can do is send them to the dev and ask what the point is and whether they can be moved to stored procs.

    EF is fine for simple queries. Sure beats writing a few hundred CRUD procedures.




    Gail Shaw
    Microsoft Certified Master: SQL Server 2008, MVP
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

    Post #1590761
    « Prev Topic | Next Topic »

    Add to briefcase 12»»

    Permissions Expand / Collapse