Al comienzo del desarrollo de nuestra aplicación, usábamos la Dependencia de SQL bastante para almacenar los resultados de la base de datos hasta que las notificaciones le indicaran a nuestra aplicación que obtuviera una copia nueva.

Durante las pruebas, hemos notado que el rendimiento de la dl de sql estaba siendo golpeado por el servicio de notificación de dependencia de sql. Reducimos la cantidad de tablas en las que estábamos usando la dependencia de SQL y notamos una gran ganancia en el rendimiento. Entonces, pensamos que estábamos por usarlo y seguimos adelante. Estamos a sólo unas pocas mesas ahora.

Más tarde, descubrimos que no podíamos reducir el nivel de acceso de seguridad para el nombre de usuario que establecerá la dependencia. Podríamos tener más de una cadena de conexión para cada db (una para la dependencia y otra para el resto de la aplicación), pero con múltiples duplicaciones de db y db, esto es una molestia (desde el punto de vista del administrador de sql db y el desarrollo de la aplicación)

En este punto, solo estamos pensando en alejarnos de la dependencia de SQL por completo en base a la siguiente lógica:

No necesitamos una notificación "instantánea" de que los datos han cambiado. Si supiéramos en 1 segundo, sería lo suficientemente rápido.Con un poco de re-factorización, podríamos reducirlo a solo 1 tabla y sondear esa tabla una vez por segundo.

¿Alguien ve una falla en esta lógica?

¿Encuestar una tabla una vez por segunda causaría más o menos carga en la base de datos que la dependencia de SQL?

¿Alguien ha tenido un problema de rendimiento similar con la dependencia de SQL?