Planear notificaciones
Para utilizar notificaciones de consulta de forma efectiva, debe tener en cuenta si la aplicación puede beneficiarse del uso de las mismas, si las consultas que utiliza la aplicación admiten notificaciones, así como la estrategia que la aplicación va a utilizar para suscribirse y recibir notificaciones.
Las notificaciones de consulta proporcionan una forma cómoda de reducir los ciclos de ida y vuelta a la base de datos si los datos de la consulta se modifican con relativa poca frecuencia, si la aplicación no precisa de una actualización instantánea cuando se modifican los datos y si la consulta cumple los requisitos y las restricciones que se indican en Crear una consulta de notificación. Muchas aplicaciones basadas en Web cumplen estos criterios, lo que permite que se beneficien de las notificaciones de consulta.
No todos los escenarios pueden beneficiarse de las notificaciones de consulta. Las notificaciones de consulta son útiles en situaciones en las que una aplicación lee los datos de una base de datos con frecuencia, pero en las que las actualizaciones de datos son poco frecuentes. Por ejemplo, la información de una aplicación de catálogo en línea se consultará con más frecuencia que las veces que se actualice el catálogo. Sin embargo, en el caso de un carro de la compra en línea, el contenido de un particular puede actualizarse con mucha frecuencia, por lo que las notificaciones de consulta son menos beneficiosas.
Las notificaciones de consulta son más eficaces cuando una aplicación emite consultas que comparten una estructura común y que sólo presentan variaciones en los valores de los parámetros. Por ejemplo:
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
En este caso, las suscripciones de notificaciones de consulta de ambas notificaciones comparten la misma plantilla interna, lo que requiere una menor sobrecarga de SQL Server que dos notificaciones con una estructura de consulta distinta. Tenga en cuenta, no obstante, que se conservan los parámetros de las consultas. Aunque las consultas compartan una misma plantilla, al agregar un elemento con un valor de 350 para ListPrice, se producirá una notificación de la segunda consulta, pero no de la primera.
Cuando las notificaciones de consulta están activas en una tabla, las actualizaciones de la tabla resultan más costosas. El Database Engine (Motor de base de datos) realiza un trabajo adicional para comprobar las suscripciones y, si es necesario, generar notificaciones. La reutilización de las plantillas internas ayuda a minimizar la sobrecarga por suscripción. Por lo tanto, sólo debe utilizar notificaciones de consulta para las aplicaciones que envíen consultas con una estructura similar. Una aplicación que envíe consultas con distintas estructuras no debería utilizar notificaciones de consulta.
Por ejemplo, una aplicación que muestre los elementos del catálogo comprendidos en un intervalo de precios determinado enviará consultas con la misma estructura. En este caso, el Database Engine (Motor de base de datos) podrá reutilizar la plantilla interna para cada consulta, y las notificaciones de consulta serán capaces de mejorar el rendimiento. Sin embargo, una aplicación que permita la creación de informes ad hoc enviará consultas con una estructura variable. En este caso, la aplicación no debería utilizar notificaciones de consulta.
El Database Engine (Motor de base de datos) mantiene una plantilla interna siempre y cuando haya una suscripción registrada, como mínimo, que utilice dicha plantilla. El Database Engine (Motor de base de datos) limita el número de plantillas internas distintas de una tabla específica. Una vez alcanzado este límite, el Database Engine (Motor de base de datos) no registra las suscripciones que darían lugar a la creación de una nueva plantilla. En lugar de ello, el Database Engine (Motor de base de datos) genera inmediatamente un mensaje de suscripción que indica que la suscripción no se ha podido registrar.