tag route page net for asp asp.net linq-to-sql jquery-ui data-access-layer sql-server-2008-r2

asp.net - route - select asp-for asp-items



Optimización de Autocompletar para grandes conjuntos de datos (2)

Estoy trabajando en un gran proyecto en el que tengo que presentar una forma eficiente para que un usuario ingrese datos en un formulario.

Tres de los campos de esa forma requieren un valor de un subconjunto de una fuente de datos común (tabla SQL). Usé JQuery y JQuery UI para construir un autocompletar, que se publica en un genérico HttpHandler.

Internamente, el controlador utiliza Linq-to-sql para captar los datos requeridos de esa tabla específica. La tabla tiene aproximadamente 10 columnas diferentes, y la expresión linq usa SqlMethods.Like () para coincidir con el término de búsqueda único en cada uno de esos 10 campos.

El problema es que esa tabla contiene unas 20,000 filas. El autocompletado funciona sin problemas, acepta el gran volumen de datos que introduce los desajustes, en las proximidades de 6 segundos aproximadamente (cuando se depura en mi máquina local) antes de que aparezca.

El autocompletado de JqueryUI tiene 0 retrasos, consultas en la tecla 3 y el resultado de la publicación se realiza en un estilo de Facebook de varias filas seleccionables. (Casi tuve que reescribir el complemento de autocompletar ...).

Entonces, el problema es datos vs. velocidad. ¿Alguna idea sobre cómo acelerar esto? Los únicos dos pensamientos que tuve fueron almacenar en caché los datos (¿Cómo / Dónde?); o utilice un lector de datos sql directo para acceder a los datos?

¡Cualquier idea sería muy apreciada! Gracias,

<bleepzter/>


Me gustaría ver solo devolver el primer número X de filas usando el método .Take .Take(10) linq. Eso debería traducirse en una llamada sql sensbile, que pondrá mucha menos carga en su base de datos. A medida que el usuario escriba, encontrará cada vez menos coincidencias, por lo que solo verán los datos que necesiten.

Normalmente considero que 10 elementos son suficientes para que el usuario entienda lo que está sucediendo y aún así obtenga los datos que necesita rápidamente (consulte la barra de búsqueda de amazon.com para ver un ejemplo).

Obviamente, si puede ordenar los datos de manera significativa, es más probable que los 10 resultados den al usuario lo que están buscando rápidamente.


Devolver los mejores N resultados es una buena idea. Encontramos (consultar una lista potencial de 270K) que devolver el top 30 es una mejor apuesta para que el usuario encuentre lo que está buscando, pero eso COMPLETAMENTE depende de los datos que está consultando.

Además, REALMENTE deberías dejar la demora en algo sensible como 100-300 ms. Cuando establece la demora en CERO, una vez que golpea el disparador de 3 caracteres, efectivamente CADA. SOLTERO. LLAVE. CARRERA. se envía como una nueva consulta a su servidor. Esto podría fácilmente tener el efecto involuntario y desagradable de ralentizar la respuesta aún MÁS.