¿Cómo puedo identificar cuándo crear una nueva tabla para contener los datos que se pueden obtener de una consulta?

Tenemos una tabla de pagos y los agentes obtienen una comisión por los pagos. La comisión se basa en algunos factores diferentes, como el tiempo que tomó obtener el pago, por lo que hay algunos cálculos involucrados al calcular la tasa de comisión que obtiene el agente, pero nada obscenamente complejo.

Por ejemplo, probablemente nunca será más complejo que esto:

SELECT Payments.Amount * CASE 
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
    WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
    ELSE Rates.Rate3 END

¿Tendría sentido construir una segunda tabla para contener estos datos en lugar de consultarlos cada vez que sea necesario? ¿O debería seguir con las consultas en tiempo de ejecución que extraen los datos cada vez que se solicitan?

Y, lo que es más importante, ¿cuáles son los factores a utilizar al determinar si una consulta debe ejecutarse cada vez que se necesitan los datos, o si los datos deben almacenarse en una tabla propia?

sql-server sql-server-2005 query-performance Rachel
fuente

Una pregunta clave es '¿con qué frecuencia las personas quieren consultar estos datos?' ¿Es un informe o una pantalla con mucho tráfico en la aplicación?

ConcernedOfTunbridgeWells

@ConcernedOfTunbridgeWells En este caso, se trata de un informe que se ejecuta varias veces al mes, tal vez con mayor frecuencia si dejamos que los agentes ejecuten el informe ellos mismos para ver su comisión.

Rachel

Probablemente sea mejor construirlo en una tabla de informes en un proceso nocturno, y la comisión es "a partir de anoche". Si tiene un proceso de cierre en el que necesita cerrar e informar, entonces podría proporcionar una instalación en la aplicación para forzar una reconstrucción.

Preocupado por

Las fechas "AsOf" son bastante comunes con este tipo de operaciones en un contexto financiero, en mi experiencia. Por lo tanto, una tabla (como señala @ConcernedOfTunbridgeWells) con una fecha "AsOf" de este tipo debería ser perfectamente aceptable.

swasheck

Publicación

Nick Chammas

Respuestas:

Si la consulta se ejecuta con poca frecuencia (por ejemplo, un informe), probablemente sea mejor construir la tabla sobre la marcha ¹ . Si la consulta se ejecuta con frecuencia y la tabla temporal es necesaria para el rendimiento, es posible que tenga un problema.

Si la tabla es barata de construir, hágalo como una tabla temporal. Mientras la base de datos sea lo suficientemente rápida, puede salirse con la suya. Sin embargo, deberá vigilar el rendimiento.
Si la tabla no tiene que estar totalmente actualizada, pero será objeto de una actividad de informes relativamente frecuente, una reconstrucción periódica es probablemente la mejor opción.
Si la tabla es costosa de construir pero necesita estar actualizada, es posible que deba administrarla como una estructura denormalizada, mantenida como una vista indexada o mediante disparadores. Esto es bastante más complicado y supone una carga adicional para las operaciones de escritura.

En casos más extremos (es decir, grandes volúmenes de datos), es posible que necesite un enfoque híbrido donde los datos históricos se consultan desde una estructura denormalizada optimizada para el rendimiento y los datos actuales se consultan desde la aplicación en vivo.

Los casos más extremos de esto pueden llevarlo a feeds de data mart de baja latencia y soluciones OLAP híbridas, por lo que este es, con mucho, el más complejo en términos de cuán profundo puede llegar el agujero del conejo. Es mejor evitarlo a menos que tenga un requisito genuino.

En el caso que describa anteriormente, una reconstrucción periódica de una tabla de informes parece apropiada. Si necesita cerrar en el medio de un día para ejecutar informes, entonces podría proporcionar una instalación para forzar una actualización desde la aplicación. De lo contrario, ejecútelo en un proceso nocturno y los agentes pueden ver su comisión "a medianoche del día hábil anterior".

^{1 las} select into consultas que crean tablas temporales son bastante rápidas en SQL Server porque las operaciones de inserción se registran mínimamente.

Para resumir, utiliza los siguientes factores para determinar si debe tener una nueva tabla para sus datos o no:

Con qué frecuencia se necesitan los datos
Qué costoso es obtener los datos
Cuán actualizados deben estar los datos

Preocupado por TunbridgeWells
fuente

Básicamente, los únicos dos factores que utiliza para determinar si necesita una tabla permanente para los datos en lugar de consultarlos cuando es necesario son how often the data is neededy how expensive the query is?

Rachel

@Rachel - Además, '¿qué tan actualizados deben estar los datos?'

Preocupado por

Una cuestión que no está cubierta en la respuesta aceptada es "¿necesita este valor con el tiempo" y "la fórmula posiblemente cambiará".

Por ejemplo, considere el ejemplo de la comisión. Si se paga la comisión, la cantidad debe almacenarse ya que es una cifra histórica de lo que realmente se pagó. La forma de calcular las comisiones podría cambiar el próximo mes (y con frecuencia lo hace), pero eso no cambiará lo que realmente se pagó, que debe almacenarse por separado.

Es la misma idea que almacenar el precio que el cliente realmente pagó por un producto (después de un cálculo de descuentos, etc.) en lugar de confiar en una fórmula contra una tabla de precios para hacer algo excepto el cálculo inicial porque el precio del producto el mes próximo podría no ser el mismo que el precio cuando el cliente hizo el pedido.

Si necesita un registro histórico de cuál era el valor en un punto en el tiempo, siempre almacene ese valor después de usar la fórmula para el cálculo inicial.

HLGEM
fuente

Gracias, definitivamente es algo a considerar al tomar este tipo de decisión. Esta vez, el valor no cambiará porque la tasa de comisión se establece una vez por agente y por cliente cuando se obtiene el cliente, y la tasa utilizada se basa en la fecha del pago y la fecha en que recibimos al cliente, ninguno de los cuales son valores que cambian

Rachel

@Rachel: ninguno de los cuales son valores que planea cambiar actualmente. Por supuesto, si se hacen cambios siempre se puede crear una tabla de datos históricos en ese momento, si lo necesita, siempre y cuando que no se olvide sobre el tema.

psr

Probablemente no sea de interés si está bloqueado en una base de datos en particular, pero MariaDB (trabajo basado en MySQL similar) tiene algo maravilloso llamado "columnas virtuales" que pueden calcularse sobre la marcha o almacenarse en caché en el almacenamiento real, pero de forma automática. recalculado según sea necesario. He echado de menos esta funcionalidad desde que dejé FileMaker Pro para el mundo SQL hace muchos años ...

Jan Steinman
fuente