¿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?

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

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.

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 ...