We're building an application with DocumentDb backend that will get lots of hits and its reponsiveness is absolutely paramount.
I wanted to see if there was a "preferred" approach from a performance stand point in querying DocumentDb. Should we use SQL for our queries or LINQ?
Theoretically, there shouldn't be a noticable difference in regards to responsiveness.
LINQ is a simply a fluent wrapper API, that which given a LINQ expression generates a SQL expression. You can view the generated SQL expression by applying toString() to the end of the LINQ expression. The performance hit on converting a LINQ expression to SQL is negligible compared the time it takes to perform I/O.
In practice, the translation from a LINQ expression may result in a sub-optimal SQL expression when dealing with corner cases. For those corner cases, working directly with SQL would be preferred.
Related
I need a help on the database access in 3-tier architecture. I am developing application in asp.net and linq. In database there are at least 9 master tables and total of 22 tables. For managing data I need to use a view for each master table.
My question is what is more convenient on runtime or for faster execution?
To use page level queries (using multiple joins having at least 5-6 tables) in DataAccessLayer using linq
To use view and refer them in DataAccessLayer
Adding all queries to a stored procedure and then bind them all.
Which one is best practice? Is views makes page heavy while runtime?
Linq2SQL queries generally wind up as parameterized queries on your database.
There are many discussions on SO comparing the difference in performance like Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS's? and Stored Procedures vs Parameterized Queries
I believe the concensus is that the benefit of the flexibility that an ORM like Linq2SQL gives generally outweighs any perceived performance loss.
IMO, LINQ2SQL will do 90% of the job just fine for most of your data access requirements, and if you have any special needs where a PROC makes more sense (e.g. a really data intensive or batch transaction), you can write one or two procs and these to your DataContext.
However, while we are at it, I wouldn't consider Linq2SQL on a new project. Why not look at Entity Framework 4+? (OP is using .NET 3.5)
Edit
If your table Foreign keys are set up correctly, when you drag your underlying tables into your Linq DBML's, you will find that you hardly ever need to join 'manually' as the ORM will handle the underlying navigation for you.
e.g.
var myUpvotes = Users.Where(u => v.UserId == someUser)
.Votes.Where(v => v.Upvote == true)
.Count();
One concept you will need is Eager vs Lazy loading. This will definitely impact the performance of your 'joins'
I think best practice would be your #1, but you must keep an open-mind about bringing #2 or #3 to bear on the problem if the performance needs demand it. In other words, run with #1 as far as you can, but be willing to use #2 or #3 to improve those parts of the code only if/when you need it.
I've found (and agree with #nonnb) that the productivity improvement and flexibility of using Linq2SQL / ORMs makes it the right choice most of the time, but there are a few times when you need to be willing to make use of a strategic SP in your overall plan - its not an either/or decision; use both as necessary. Generally SP's will be faster, but most of the time not enough to make a difference in your application - but they should be kept in your toolset because in the right scenarios, they can make HUGE improvements when they are really needed.
I am new to asp.net and I am trying to learn Linq to SQL. So I have found two different ways to pull from the database. The normal linq to SQL way and the direct SQL statement way.
I have both working, but I want to know which way is the accepted standard? I want to use straight SQL statements, because that is what I am use to, but I am trying to go with whatever is best practice.
Thanks
Take a look at the selected answer to this popular question.
Entity Framework became the preferred way to interact with a SQL database in ~2008.
Much of the heavy lifting in database calls and transactions is greatly simplified in EF.
If you continue to use Linq to SQL and want to learn from the master, have a look at Scott Guthrie's Post.
Entity Framework is to be Microsoft's best practice solution. Once you learn LINQ you will find it is much easier to code.
Personally, I much prefer using LINQ and have since the moment I learned it. You can turn on the log feature while you are learning and can see the SQL that gets created. If you have performance concerns and need to hand tweak SQL you can always revert to that. Just not having to hard code strings with table and field names makes code more maintainable and with intellisense also much more enjoyable to write.
There isn't really an accepted standard between straight SQL and LINQ (or any other ORM). It depends on what environment you're using it in, and what you want to do. However, Microsoft has announced that the LINQ to SQL project isn't going to be continued, so I suggest you consider the ADO.NET Entity Framework (which supports LINQ via LINQ to Entities) instead.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures
I am going to work with Linq data access model. Which Model performance is better? and why to use and why not to use Linq.
Thanks
There is always a trade off between abstraction level and performance, so of course, Linq To Entities or Linq To Sql, which both work on top of ADO.NET, will be slower than ADO.NET.
It is all about what level of performance you need for your particular project. If performance is more crucial for you than ease of development then go with straight DataReaders. If not then go for Linq To Entities.
Linq to SQL and Entity Framework etc. all use ADO.NET internally, thus they are slower since they do more work than ADO.NET alone.
The idea is not to get the best performance but the best abstraction, model your domain with objects so you can reason about your data and the commands that operate on that data.
So it's a good idea to trade some performance for other aspects.
I want to create a web application using ASP.NET. Which method should I use, LINQ or SQL query? Which gives the best performance? Please help me.
This is an excellent series by a CLR Performance Architect describing LINQ to SQL performance: http://blogs.msdn.com/b/ricom/archive/2007/06/22/dlinq-linq-to-sql-performance-part-1.aspx
Performance-wise I think you'll always be better off with SQL. If you take a look at the generated SQL code which LINQ produces you'll notice that it's not always that top notch.
On the other hand, LINQ isn't slow. It's not as fast as SQL, but it's definitely not slow. If you think about the advantages LINQ provides I would always prefer LINQ over SQL if I have the choice.
If performance is the BIG issue tho, sticking with SQL might be your best shot. If you were just wondering if the difference was that major, and if you don't expect database-performance to be a bottleneck I'd go for LINQ.
I'm starting a new project based on ASP.NET and Windows server.
The application is planned to be pretty big and serve large amount of clients pulling and updating high freq. changing data.
I have previously created projects with Linq-To-Sql or with Ado.Net.
My plan for this project is to use VS2010 and the new EF4 framework.
It would be great to hear other
programmers options about development
with Entity Framework
Pros and cons from previous
experience?
Do you think EF4 is ready for
production?
Should i take the risk or just stick with plain old good ADO.NET?
Whether EF4 is really ready for production is a bit hard to say since it's not officially been released yet.... but all the preliminary experiences and reports about it seem to indicate it's quite good.
However: you need to take into consideration what EF is trying to solve; it's a two-layer approach, one layer maps to your physical storage schema in your database (and supports multiple backends), and the second layer is your conceptual model you program against. And of course, there's the need for a mapping between those two layers.
So EF4 is great if you have a large number of tables, if you have multiple backends to support, if you need to be able to map a physical schema to a different conceptual schema, and so forth. It's great for complex enterprise level applications.
BUT that comes at a cost - those extra layers do have an impact on performance, complexity, maintainability. If you need those features, you'll be happy to pay that price, no question. But do you need that??
Sure, you could go back to straight ADO.NET - but do you really want to fiddle around with DataTables, DataRows, and untyped Row["RowName"] constructs again?? REALLY???
So my recommendation would be this:
if you need only SQL Server as your backend
if you have a fairly simple and straightforward mapping of one database table to one entity object in your model
then: use Linq-to-SQL ! Why not?? It's still totally supported by Microsoft in .NET 4 - heck, they even did bugfixes and added a few bits and pieces - it's fast, it's efficient, it's lean and mean - so why not??
My advice is use both. At first I thought I would only use linq to sql and never have to touch ado.net ever again ( what made me happy lol).
Now I am using both because some things linq to sql(and any ORM like EF) can't do. I had to do some mass inserts and I did it first with linq to sql and to do 500 records it took over 6mins(2 mins for validation rules rest was inserting into the db).
I changed it to sql bulk copy and now it is down to 2min and 4 seconds(4 seconds to do all inserts)
But like marc_s said I really did not want to fiddle around with DataTables, DataRows, and untyped Row["RowName"].
Say my table was like 10 columns long and called Table A. What I did was I used linq to sql and made a Table A class( new TableA()) object and populated it with data. I then would pass this object to a method that created the datarow.
So linq to sql saved me some time because I probably would have made a class as I would not have wanted to pass in 10 parameters into the method that makes the data row. I also feel it gives a bit of typeness back as you have to pass in the right object to use that method so less chance of passing in the wrong data.
Finally you can still use linq to sql to call Stored procedures and that is like one line of code.
So I would use both when ever you notice that linq to sql (or in your case EF) is slow then just write a SP and call it through EF. If you need to do straight ado.net evaluate what you need to do maybe you can use EF for most of the code(so you can at least work with objects) and only for that small portion ado.net sort of what I did with sql bulk copy.
EF 4 is now more similar to LINQ to SQL, in the good ways; it has the FK keys right in the object, has add methods right in the object sets, and a lot of other nice features. THe designer is much improved, and the major plus is that it works with SQL and Oracle, and maybe some others (as long as the provider supports it) instead of LINQ to SQL with only SQL Server.
EF is the future; the ADO.NET data services is a web service add on, plus it supports POCO and T4 generation, and any new features will support this (LINQ to SQL is maintenance only, and data sets won't be getting any changes any more).
HTH.