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 6 years ago.
Improve this question
I'm interested in your opinions, best thoughts ...
Would you say it's better to just query the database any time you want to retrieve data (even if you know it'll be static), or store the data in server(web) session memory?
On the one hand, storing in memory would allow faster processing of data, and decrease SQL server loads. On the other hand, it can somewhat increase complication of application code, and web server/system resources.
The answer depends (as most do) on your specific needs. If your database has the bandwidth but your web server doesn't, you should do it in SQL. And vice versa. There's no way to recommend anything to anyone without knowing their situation.
You can use static dictionaries to store static data from database.
The benefit of use this is have only one instance of each dictionary and reduce the number of request to the database.
You can refer to this question to see how to implement this.
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 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
We have configuration data stored within the tables like casestatustypes with columns such as statusid, name, description. How to store these kind of data in the web application, instead of hitting the database each time for retrieving the statusid.
You use a technique known as caching. Basically, you build an in-memory copy of the data that you use for retrieval purposes. When you start the application, you pull from the database to create this cache. When you do an insert, update, or delete; you do it to both the cache and database.
Its easy enough to implement yourself, and there are several good libraries out there (Microsoft even has one in Enterprise Library http://msdn.microsoft.com/library/cc467894.aspx).
Gotchas:
If the data set is large, you'll want to implement a caching strategy that doesn't hold the entire dataset in memory (libraries are useful for this).
Since its a web-app, you need to make sure the cache isn't going to be re-created for each session.
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’m using Entity Framework and Sql Server 2012. I have to remove in one Transaction a lot of items from database about 200 GB. I’m deleting the data now directly this is very fast!
The problem if the deleting process is failed the database will be defected that why I’m thinking to use Transactionscope. When the process failed I will Rollback the database.
Is Transactionscope good to handle a lot of data or we have to make some consideration about the performance. Anyone have some benchmark data or experience with this problem?
Any help would be greatly appreciated
As they have said in the comments it has some impact but it is trivial if you decompile TransactionScope class and look to the code you will see what it happening there!
It is really depending on your Database settings/Schema; you can optimize your database to get the best results. This approach have been used for years and I have used for long time until now I have no problem with it.
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
If any of you are using the new TVP to pass a collection to SQL Server what issues have you encountered with that process? I am thinking about implmenting it, but wanted to get some feedback on potential pitfalls with going with that solution. I like passing XML for flexibility and the ability to pass collections, but I don't want to have to shred the xml with SQL Server (Doesn't seem like it will scale well). Anyways just wanted to get some feedback from some of the more experienced users....always really helpful.
Thanks,
S
I have been using TVPs for half a year so far, and I did not have any issues at all. I do not send more than 1K rows at a time. Before TVPs were available, I was packing numbers in binary format into an image, and casting parts of an image back into numbers on the server - that scaled very well, performed real fast for up to 100K numbers.