Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
LINQ just seems to generate horrendously optimised SQL (in general). I can write way more efficient T-SQL myself.
Do huge websites with my thousands of daily visitors use LINQ? Or should LINQ at some point be ditched? And if so, with what? and when?
Do huge websites with my thousands of daily visitors use LINQ?
Yes. Why not? Most SQL is trivial and you can always fall back to a stored procedure where it matters.
And that is the point. Let LINQ handlethe easy 80% and focus on the more complex.
And ther rest you handle by not talking to the database - caching is not that hard to plan for.
What I have done with my apps, when L2S or EF creates inefficient T-SQL is to create a view that does exactly what I want, in an efficient manner and I just have L2S or EF query the view.
In fact, this website (stackoverflow) uses linq2sql extensively, although I believe they are using a micro-orm (sqlfu?) for some of the heavier taks..
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What are the effects of Linq on an application rather than SQL queries?
Is there is any issue in using Linq in case of large amount of data for a long time of period?
What are the behavioral key difference between both?
Simple advantages
Creating in-memory collections
for a number of situations it would be easier to read and write. (note there are some queries that would make more sense in SQL)
Allows you to call C# functionality that you create or from the .net framework to interact with your data.
In some cases it is easier to debug.
For a more in depth and correct answer go to Learning about LINQ
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose you would develop a big enterprise application with complex business logic and over 100 entities where each of them has 15 properties.
Would you say that Entity Framework is suitable in this case. Or will it cause too much headaches?
Yes I know this question is opinion based. But that is exactly what I want, the opinion of the developers who have been working with big projects.
We use EF with a fairly large database, well over 100 entities, many of them with a lot more than 15 properties.
Any ORM is going to be slower than raw SQL, but you have to balance the benefits. If you find performance is an issue, you can address specific areas and optimise them. For example, if you have an entity with a lot of properties, and you query it like this...
var jim = ctx.MyEntities;
...you may see performance suffer as the number of entries in the table grows. If you modify your query to do this...
var jim = ctx.MyEntities
.Select(j => new{
Jim1 = j.Jim1,
// other properties as needed
});
...and only pull out the properties you actually need, you'll find it a lot faster.
Hope that helps.
Like anything, it's fine provided you use it appropriately.
Personally I have not hit any scale problems while using it for OLTP where it makes for great savings in development time and quality, albeit at the expense of some relatively minor inefficiencies.
Where it has let me down is bulk/batch processes, reporting and other large aggregations, even when the resulting rows can be small. In these cases it's well worth stepping out of pure EF and adding some views or stored procedures. These can then be used through EF with the typical benefits.
Keep an open mind and play to its strengths, be flexible and you should be ok.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently learning LINQ especially SQL requests with the entity framework.
I used to write native SQL-queries before, and I've implemented it with one class in my projects called "SQL_Connection" or something.
So I had all my SQL-procedures stored in one class.
Now as I'm willed to learn the entity framework the right and cleanest way from beginning, I'm asking myself where do I put all those linq-procedures I create during a project.
Do expierienced people put them in the class-file of the related class, or are they using a big sql-class where all those procedures are stored in?
I'm asking myself where do I put all those linq-procedures I create during a project.
Where you create them.
If you are not totally ignorant on .NET you will have a TON of LINQ queries and only SOME will be EF related - the syntax is the same. You will use LINQ in your code to sum and aggregate in memory arrays, and do a lot of things.
The beauty of LINQ is that all changes to the underlying provider are isolated and / or checked by the compiler, so there is no need to have all in one place "in case I rename a table".
I keep the LINQ where I need it. This allows me to isolate layers without having a mother of all queries class. Especiall as some of the LINQ queries are multi step queries involving one or more data access then grouping and correlating in memory.
Seriously, the "one class to rule them all" (sql) is an artefact of the fact that SQL is a string, so in case of a database change you need to find all SQL that touches that changed element and that please without going through tons of code. This is absolutely not needed with LINQ.
That's up to your pleasure. Answering the question: do create BLL classes for your related set of objects. By this, a minor change won't make you itchy. Assume you added a new column to a table, having that table's (and other related ones') operations located easily is good, right? Avoid too big files. Try to stay modular and etc.
If you need a reading, check out this Wiki link about MVC architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I gonna write a new Program,
is it better to store my Queries in Views and call them from my C# Code.
Or should i Just execute all SQL queries in my Code.
Which is better for the Performance.
From a performance point of view there is no difference between running a query from C# and accessing a view that is based on the same query; the only difference would be if the view that you are accessing has indexes on it and thus runs faster than your ad-hoc query.
As a good practice is best to use SQL View when extracting data from multiple tables through joins as putting the whole SQL code in C# would look messy and might be more prone to errors.
There are a lot of things to be considered when undertaking this:
1. volume of data - indexed views
2. number of tables involved
3. database structure dynamic - how often you change tables
have fun!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am working on a collaborative-filtering recommender system. I built such a system before in a parallel-threaded environment, querying RDF with SPARQL. This worked well, because of the parallel nature of SPARQL and RDF graphs. However, I am now working in a standard desktop PC, and am wondering if using SPARQL is still the way to go in a largely serial environment. I've looked at dotNetRDF, as I'm using C#, and am wondering if it is any more efficient than simple SQL, especially now that dotNetRDF seems to be moving away from a SQL back-end.
So as far as performance on a few threads go, SQL or dotNetRDF? Tables or graphs?
The two things are not really comparable, dotNetRDF is a programming API that provides support for a variety of storage backends in addition to a pure in-memory solution which we mainly recommend for testing and development (Disclaimer I'm the lead developer)
The different backends have a wide variety of performance characteristics so if your problem is expressible in RDF then likely there is an appropriate backend for you.
SQL is a query language, really you should be comparing SQL to SPARQL and ultimately which you chose comes down to what your data model looks like. If it's regular then you likely want to use a RDBMS and SQL, if it's irregular and/or graph like then you likely want to use a triple store and SPARQL. The two have different pros and cons as your own answer implies.
This seems to answer it well enough. Triple Stores vs Relational Databases
Essentially, RDF is much more flexible, but expensive. Since I'm just doing collaborative filtering with data that fits pretty well into a table, I don't think I need the extra expense, as much as I like graphs.