Escucha de WebSocket para Microsoft SQL Database

Question

Actualmente estoy trabajando en un proyecto que tiene que usar WebSockets como una forma de transferir datos a mi cliente. La infraestructura se ve así.
cliente -> Servidor Web -> Base de datos de Microsoft SQL

Creo que la situación más ideal sería así: cliente abre un socket con el servidor. El servidor abre un socket a la base de datos Microsoft SQL. Cada vez que se actualiza la base de datos (se han insertado algunos datos), el DB escribe los datos en el socket. El servidor escribe los datos nuevamente en el cliente. Esto puede ser un poco tedioso, ¿tal vez de alguna manera puedo abrir un socket al DB directamente desde el cliente?

Quiero saber si hay una manera de notificar automáticamente el socket al servidor web si se actualiza la base de datos MSSQL, para que pueda procesar esa información.

La pregunta principal es realmente; ¿Cómo voy a hacer que esto funcione? He investigado algunos proyectos que funcionan con WebSockets como Node.JS y Socket.IO, también Tornado. Aunque no he encontrado ninguna pista sobre dónde buscar esta característica específica. He encontrado algunos controladores bastante inestables para las bases de datos MSSQL para NodeJS, pero no entiendo si hay alguna manera de hacer un socket al DB y enviar instantáneamente los datos a través del socket cuando se bombea a la base de datos.

También me doy cuenta de que hacer un socket entre cliente y db no sería inteligente para decir lo menos posible en seguridad, ya que no es un problema, y ​​ese SQL no es el camino para aplicaciones en tiempo real, pero ' m ligada a él por ahora :)

Edición 1:

Gracias a @tomfanning ahora sé de una solución a este problema, pero serias dudas de la mejora en el rendimiento. Déjame imaginar la situación para ti. En el caso de que use el disparador en la base de datos MSSQL, me imagino que esto sucederá.

Situación 1

1. La base de datos se actualiza
2. se aprieta el gatillo
3. El guión CLR establece una conexión con el servidor Web. Ya sea a través un enchufe que tiene que abrir y cerrar para cada disparo o a través de una solicitud HTTP (S), que implica la apertura y cierre de una Header (que es sobrecarga inútil)
4. el servidor Web recibe el gatillo y Emite los datos al cliente .
5. Actualizaciones del cliente.

Y ahora imagine el mismo escenario, pero luego con AJAX

Situación 2:

1. Un tiempo de espera de 1000 ms se establece en el cliente para AJAX pide
2. El cliente se ha agotado el tiempo y realiza una solicitud de AJAX
3. La base de datos ejecuta algunas consultas y publica el resultado
4. Actualizaciones del cliente.

En la situación 1 necesita una solicitud y un socket emit/receive y en la situación 2 solo necesita una solicitud. Si tuviera que configurar el tiempo de espera de la solicitud de AJAX en 10MS, ¿le parecería al usuario como si fuera una aplicación en tiempo real como un websocket? ¿O la situación 1 sería aún más eficiente y estoy exagerando?

¡Gracias de antemano!

Answer 1

La solución posible podría ser T-SQL triggers on INSERT or UPDATE con un CLR procedure que envía una notificación a su aplicación principal, que luego transfiere datos a su cliente a través de websockets. Evitaría tener que sondear la base de datos.

Según su comentario, no estoy seguro de cómo AJAX lo ayudaría específicamente en este caso, porque al tratarse de una tecnología impulsada por el cliente (navegador), su solución volvería a sondear, lo cual entiendo que desea evitar. WebSockets suena como la opción adecuada aquí porque le da la capacidad de hacer verdadero "push" desde el servidor al cliente sin necesidad de una encuesta.

Obviamente estoy hablando en términos muy generales y teóricos aquí.