c# - property - title attribute in html

Uso de la dependencia de SQL frente al sondeo periódico de una tabla(impacto en el rendimiento)

Question

Al comienzo del desarrollo de nuestra aplicación, usábamos la Dependencia de SQL bastante para almacenar en caché los resultados de la DB hasta que las notificaciones le indicaron 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 ahora a sólo unas pocas mesas.

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:

1. 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.
2. Con un poco de re-factorización, podríamos reducirlo a solo 1 tabla y sondear esa tabla una vez por segundo.

¿Alguien ve un defecto 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?

Answer 1

Me atrevo a intentar responder a tu pregunta. Pero no estoy seguro de que obtengas la respuesta que esperabas ...

Recuerdo que a principios de los años 90, cuando Borland promovió esta gran nueva característica de "devoluciones de llamada" en su base de datos Interbase que le daría a la persona que llama (Delphi) "notificaciones" a través de una tecnología muy ingeniosa donde se prometió que la base de datos podría estar "activa". ''.

Esto fue conocido más tarde como la " teoría del desperdicio de tiempo ".

Y supongo que la razón por la que esto nunca ocurrió fue tal vez que, si bien el concepto de DBMS parecía muy prometedor, la base de datos es uno de sus niveles que solo puede ampliar y no horizontalmente.

Así que programamos lenguajes para el rescate. O más bien la idea de Arquitectura Orientada a Servicios (SOA). Muchos confunden la SOA con los "servicios web" que de hecho se incluyeron en este nuevo concepto.

Pero si revisa el patrón de diseño Fiefdom / Emissary (o el patrón Master / Agent cuyo nombre ha cambiado para que suene más atractivo y profesional), encontrará que la idea principal es tener un control exclusivo de sus recursos (leer bases de datos) y que todas las llamadas están siendo canalizados a través de un único adaptador de datos.

Obviamente, un diseño de este tipo no funciona en absoluto con los activadores ni con ningún marco de devolución de llamada.

Pero creo que deberías reconsiderar todo tu diseño. Si canaliza todas las acciones y todas las llamadas a través de un único ''DataLayer'', tal vez utilizando Entity Framework, y quizás encima de eso, no tendría que depender de su base de datos para reenviar los mensajes de la cadena alimentaria.

Para mostrar lo extrañas que pueden llegar las cosas al estar en "centrado en la base de datos", aquí hay un ejemplo real extremo de cómo no enviar un correo electrónico, escrito hace mucho tiempo, por un programador que no me impresionó tanto:

Hecho 1: Sql Server puede enviar correos electrónicos.

Dato 2: el codificador Asp3 no sabe si o cómo puede hacerse esto en VbScript.

Asp3: leer la dirección de correo electrónico del cuadro de texto, enviar a com + layer

Com +: toma la dirección de correo electrónico y reenvía a datalayer

Datalayer: tome la dirección de correo electrónico y envíela a un procedimiento almacenado

Sproc: toma la dirección de correo electrónico y la reenvía a la función SQL

función: hacer cosas raras de sub-cadenas para verificar que la dirección de correo electrónico tiene @. en eso. devuelve verdadero o falso.

Sproc: devuelve un conjunto de registros con una columna y una fila que contiene 1 o 0

Datalayer: devuelve la tabla como está.

Com +: convierte la primera columna y fila con el valor 1 o 0 a verdadero o falso

Asp3: si es cierto, envíe una dirección de correo electrónico con el asunto del correo electrónico y el texto del correo electrónico a com +

Com +: envía la información exacta a datalayer

Datalayer: llama a un procedimiento almacenado ..

Sproc: llama a una función sql ...

Función: utiliza el agente de correo electrónico del servidor SQL para enviar el correo electrónico.

Si lees esto hasta ahora, mi consejo es que dejes que el servidor SQL administre tablas, relaciones, índices y transacciones. Es muy bueno en eso. Cualquier cosa más allá de esas tareas, y con eso sí incluyo cursores en procedimientos almacenados, se maneja mejor a través del código apropiado.