tags:

views:

1714

answers:

4

OK, First let me state that I have never used this control and this is also my first attempt at using a web service-- My delima is as follows. I need to querry a database to get back a certain column and use that for my autocomplete. Obviously I dont want the querry to run everytime a user types another word in the textbox, so my best guess is to run the querry once then use that dataset, array, list or whatever to then filter for the autocomplete extender... I am kinda lost any suggestions??

+2  A: 

This question depends upon how transactional your data store is. Obviously if you are looking for US states (a data collection that would not change realistically through the life of the application) then I would either cache a System.Collection.Generic List<> type or if you wanted a DataTable.

You could easily set up a cache of the data you wish to query to be dependent upon an XML file or database so that your extender always queries the data object casted from the cache and the cache object is only updated when the datasource changes.

Ian Patrick Hughes
+2  A: 

Why not keep track of the query executed by the user in a session variable, then use that to filter any further results?

The trick to preventing the database from overloading I think is really to just limit how frequently the auto updater is allowed to update, something like once per 2 seconds seems reasonable to me.

What I would do is this: Store the current list returned by the query for word A server side and tie that to a session variable. This should be basically the entire list I would think. Then, for each new word typed, so long as the original word A exists, you can filter the session info and spit the filtered results out without having to query again. So basically, only query again when word A changes.

I'm using "session" in a PHP sense, you may be using a different language with different terminology, but the concept should be the same.

Nicholas Flynt
I'm a big fanb of serializing objects and storing them as session vars. But, a session would only be good if the query was user specific. If it was application wide then you would end-up with redundant data stored for each query.
Ian Patrick Hughes
+1  A: 

RAM is cheap and SQL is harder to scale than IIS so cache everything in memory:

  1. your entire data source if is not too large to load it in reasonable time,
  2. precalculated data,
  3. autocomplete webservice responses.

Depending on your autocomplete desired behavior and performance you may want to precalculate data and create redundant structures optimized for reading. Make use of structs like SortedList (when you need sth like 'select top x ... where z like @query+'%'), Hashtable,...

Bartek Szabat
A: 

While caching everything is certainly a good idea, your question about which data structure to use is an issue that wasn't fully answered here. The best data structure for an autocomplete extender is a Trie. You can find a good .NET article and code here.