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

Optimizing Your Application - Part 2 Expand / Collapse
Author
Message
Posted Sunday, February 22, 2004 7:20 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, July 3, 2014 1:41 AM
Points: 175, Visits: 106
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnis
Post #101634
Posted Wednesday, February 25, 2004 3:15 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, October 8, 2013 2:59 PM
Points: 383, Visits: 57

As an application designer I should not have to concern myself with caching data for the purpose of improving performance.

If caching data I need to write code that determines when the cache needs to be updated.

As an application developer I am more concerned about developing business logic that helps users perform there jobs with greater efficiency and ease.

Providing good database performance should be the domain of the developers of the DBMS and the database administrators.



Keith
Post #102168
Posted Wednesday, February 25, 2004 7:06 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, July 7, 2014 12:50 PM
Points: 292, Visits: 264

You're not concerned with performance? I bet your users are and if they don't get reasonable performance then they can't work with "greater efficiency and ease" can they?

Eliminating server round trips is especially important in stateless environments because new connections often need to be made to the server and this is particularly expensive. If you're using .NET, an easier item to cache though would be a dataset or datatable (Preferably typed).

That said, Keith does make a good point. Caching should not be done unless you actually need to optimize performance. In this economy, throwing hardware at it is not the solution and developers and DBA's need to work together on optimizing DB operations. That is why Microsoft made SQL Server easier to manage than many other DBMS's, so they can spend more time with developers designing databases - thatis where the performance benedits come in; up front.

 



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #102226
Posted Wednesday, February 25, 2004 7:28 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 9:03 AM
Points: 519, Visits: 2,802

Using a HashTable might not be a good idea. HashTable orders its items by internal hashcode, so if you're expecting items to be in a particular order (e.g. either sorted or in the order that you put them into the collection), you might be in for a nasty surprise.

Why not just use a DataSet instead?




Post #102237
Posted Wednesday, February 25, 2004 7:38 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, October 8, 2013 2:59 PM
Points: 383, Visits: 57

Bryant, I did not say that I was not concerned with performance!

 

I think caching is only useful if you have data that is relatively static. I think that other solutions should be consideration before deciding to cache anything.



Keith
Post #102244
Posted Wednesday, February 25, 2004 8:04 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Tuesday, September 6, 2005 10:53 AM
Points: 107, Visits: 1

I like hashtables (and use them when I need quick 1-1 lookups), but for UI elements or other sequential-access type things, why not just keep the dataset/datatable around as long as you need it?

If you don't need really speedy data access and the dataset you have is small, you can even do a select/filter on the dataset to narrow the set you have without going back to the database.  OTOH, I found in a set of 10K records that it was much faster to ask the database to query and narrow for me than it was to use the dataset.

-Thor Johnson




Post #102262
Posted Wednesday, February 25, 2004 9:00 PM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, July 3, 2014 1:41 AM
Points: 175, Visits: 106

No doubt you can increase performance of the application by eliminating round-trips and re-querying. I have much experience with this type of application and I have applied this scenario not only with small amount of data but large amount of data. But think twice weather the data should be cached or not because it depend on various things such as application type, data type (how often data is modified) and memory.

 

Why I used HashTable for this is: it is a dictionary type collection that is optimized for fast retrieval. I do not think that DataSet is really applicable for this operation.

 

Dinesh

 

Post #102455
Posted Friday, February 25, 2005 4:40 AM
SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Thursday, June 26, 2014 3:32 AM
Points: 122, Visits: 105

The Dataset class is designed to cache data.  Why create another structure to hold multiple datasets each with one table, when you can create one dataset with multiple tables? 

 

Post #164016
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse