Which Method is More Efficient?
Hello,
I'm trying to decide which of two methods I should use for a project I am working on. The project involves retrieving data to populate 14 different drop-downs, but what you choose in one drop-down could change what you see in another drop down.
I am contemplating two different ways to do it.
1) Do a SQL Server query every time a drop-down changes. This obviously would get the data as I need it, but I could hit the database many times depending on how often someone changes the values they choose in any given drop down.
2) Do one big query that returns all the data I may possibly need (could return over 1500 records), store that data in the .NET Application Cache, and then use LINQ to filter out that cached data and return the data I need based off user selection.
Which would be more efficient? Is there another method that's even better that I haven't thought of?
Thanks!
Jeremy
I'm trying to decide which of two methods I should use for a project I am working on. The project involves retrieving data to populate 14 different drop-downs, but what you choose in one drop-down could change what you see in another drop down.
I am contemplating two different ways to do it.
1) Do a SQL Server query every time a drop-down changes. This obviously would get the data as I need it, but I could hit the database many times depending on how often someone changes the values they choose in any given drop down.
2) Do one big query that returns all the data I may possibly need (could return over 1500 records), store that data in the .NET Application Cache, and then use LINQ to filter out that cached data and return the data I need based off user selection.
Which would be more efficient? Is there another method that's even better that I haven't thought of?
Thanks!
Jeremy
Kent Olsen
For only 1,500 rows, you'll probably find that you like the performance a lot better if you read them all into your application and do the filtering there.
ASKER
Kdo,
Thanks for the response! Interesting. I've always heard LINQ is really expensive, so I'm surprised by your answer. Perhaps I heard incorrectly.
I'll wait a bit before accepting as solution in case anyone else wants to ring in.
Thanks again!!
Thanks for the response! Interesting. I've always heard LINQ is really expensive, so I'm surprised by your answer. Perhaps I heard incorrectly.
I'll wait a bit before accepting as solution in case anyone else wants to ring in.
Thanks again!!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You might consider a hybrid approach also. You could put your most-frequently accessed items into the cache, and then the lesser-queried objects would be retrieved from the database. You'd want to design this carefully, though, because it could get hairy if you don't strike the right balance.
Another issue that might influence your choice here is with changes in the base data. Cached data will reflect the data at the time it was cached, not necessarily the current data....so you might be sticking your users with out-of-date data.
ASKER
Thanks, everyone, for the thoughts.
Jens: Regarding cached data, this data won't change that frequently. And if it does, our admin tool resets the app pool in IIS, so the cache would be released and regenerated with new data anyway.
kaufmed: that is a good idea, but in this particular instance, the items will be used equally. I can totally see that solution in a different application however.
james: This is what I was thinking. Storing 1500 records when only a handful of them will be used per drop-down seems to be wasteful. I just didn't know if it was more "wasteful" to do it that way or to hit the database frequently that would return small data sets.
Jens: Regarding cached data, this data won't change that frequently. And if it does, our admin tool resets the app pool in IIS, so the cache would be released and regenerated with new data anyway.
kaufmed: that is a good idea, but in this particular instance, the items will be used equally. I can totally see that solution in a different application however.
james: This is what I was thinking. Storing 1500 records when only a handful of them will be used per drop-down seems to be wasteful. I just didn't know if it was more "wasteful" to do it that way or to hit the database frequently that would return small data sets.
..but in this particular instance, the items will be used equallyI'd wager to say that the items in the very first drop-down will be used more than the rest ; )
ASKER
kauf,
You're right. The first drop down will always be the same depending on which of the 8 products you pick. Unfortunately, in this case, the first drop down will only 2-3 options so I don't know how much of a benefit it will be to cache that.
In fact, the most options one would see in any given drop down is 7. There could be 1500+ records (SKUs) for one product because the 14 different product configuration option possibilities, but when you start filtering the options down, the number of possibilities drops quickly.
You're right. The first drop down will always be the same depending on which of the 8 products you pick. Unfortunately, in this case, the first drop down will only 2-3 options so I don't know how much of a benefit it will be to cache that.
In fact, the most options one would see in any given drop down is 7. There could be 1500+ records (SKUs) for one product because the 14 different product configuration option possibilities, but when you start filtering the options down, the number of possibilities drops quickly.