Realmente no tiene tantas formas de detectar cambios en SQL 2005. Ya enumeró la mayoría de ellos.
Notificaciones de consultas . Esta es la tecnología que impulsa SqlDependency y sus derivados, puede leer más detalles en La Notificación Misteriosa . Pero QN está diseñado para invalidar resultados, no para notificar de forma proactiva el cambio de contenido. Solo sabrás que la tabla tiene cambios, sin saber qué cambió. En un sistema ocupado, esto no funcionará, ya que las notificaciones llegarán de forma casi continua.
Lectura de registros . Esto es lo que usa la replicación transaccional y es la forma menos intrusiva de detectar cambios. Desafortunadamente solo está disponible para componentes internos. Incluso si logra comprender el formato del registro, el problema es que necesita ayuda del motor para marcar el registro como 'en uso' hasta que lo lea, o puede que se sobrescriba. Solo la replicación transaccional puede hacer este tipo de marcado especial.
Comparación de datos . Confíe en las columnas de marca de tiempo para detectar cambios. También se basa en extracción, es bastante intrusivo y tiene problemas para detectar eliminaciones.
Capa de aplicación . Esta es la mejor opción en teoría, a menos que se produzcan cambios en los datos fuera del alcance de la aplicación, en cuyo caso se desmorona. En la práctica hay siempre cambios que ocurren fuera del alcance de la aplicación.
Activadores . En última instancia, esta es la única opción viable. Todos los mecanismos de cambio basados en disparadores funcionan de la misma manera, ponen en cola la notificación de cambio a un componente que supervisa la cola.
Siempre hay sugerencias para hacer una notificación síncrona estrechamente acoplada (a través de xp_cmdshell, xp_olecreate, CLR, notificar con WCF, lo que sea), pero todos estos esquemas fallan en la práctica porque son fundamentalmente defectuosos:
- no tienen en cuenta la consistencia de las transacciones y las reversiones
- introducen dependencias de disponibilidad (el sistema OLTP no puede continuar a menos que el componente notificado esté en línea)
- funcionan horriblemente ya que cada operación DML tiene que esperar una llamada RPC de algún tipo para completar
Si los disparadores en realidad no notifican activamente a los oyentes, sino que solo ponen en cola las notificaciones, hay un problema al monitorear la cola de notificaciones (cuando digo 'cola', me refiero a cualquier tabla que actúe como una cola). El monitoreo implica buscar nuevas entradas en la cola, lo que significa equilibrar correctamente la frecuencia de las comprobaciones con la carga de cambios y reaccionar a los picos de carga. Esto no es trivial en absoluto, en realidad es muy difícil. Sin embargo, hay una declaración en el servidor SQL que tiene la semántica para bloquear, sin tirar, hasta que los cambios estén disponibles:ESPERAR(RECIBIR) . Eso significa Service Broker. Mencionaste SSB varias veces en tu publicación, pero tienes, con razón, miedo de implementarlo debido a la gran incógnita. Pero la realidad es que es, por mucho, la mejor opción para la tarea que describiste.
No tiene que implementar una arquitectura SSB completa, donde la notificación se envía hasta el servicio remoto (eso requeriría una instancia remota de SQL de todos modos, incluso una Express). Todo lo que necesita para ser cómplice es desvincular el momento en que se detecta el cambio (el activador DML) del momento en que se envía la notificación (después de que se confirma el cambio). Para esto, todo lo que necesita es una cola y un servicio de SSB local. En el disparador, ENVIAR una notificación de cambio al servicio local. Después de que se confirme la transacción DML original, el procedimiento de servicio activa y entrega la notificación, usando CLR por ejemplo. Puede ver un ejemplo de algo similar a esto en T-SQL asíncrono .
Si sigue ese camino, hay algunos trucos que deberá aprender para lograr un alto rendimiento y debe comprender el concepto de entrega ordenada de mensajes en SSB. Te recomiendo leer estos enlaces:
- Reutilización de conversaciones
- Escribir procedimientos de intermediario de servicios
- Demostración de SQL Connections 2007
Sobre los medios para detectar cambios, SQL 2008 aparentemente agrega nuevas opciones:Change Data Capture y Change Tracking . Hago hincapié en 'aparentemente', ya que en realidad no son tecnologías nuevas. CDC utiliza un lector de registros y se basa en los mecanismos de replicación transaccional existentes. CT usa disparadores y es muy similar a los mecanismos de replicación de Merge existentes. Ambos están pensados para conectarse ocasionalmente sistemas que necesitan sincronizarse y, por lo tanto, no son apropiados para la notificación de cambios en tiempo real. Pueden completar las tablas de cambios, pero le queda la tarea de monitorear estas tablas en busca de cambios, que es exactamente desde donde comenzó.
