Resultados de la función de almacenamiento en caché en SQL Server 2000

Question

Quiero memorizar los resultados de la función para el rendimiento, es decir, rellenar de forma perezosa un caché indexado en los argumentos de la función. La primera vez que llamo a una función, la memoria caché no tendrá nada para los argumentos de entrada, por lo que la calculará y almacenará antes de devolverla. Las llamadas posteriores solo usan el caché.

Sin embargo, parece que SQL Server 2000 tiene una estúpida regla arbitraria sobre las funciones que son "deterministas". INSERTES, ACTUALIZACIONES y llamadas a procedimientos almacenados regulares están prohibidos. Sin embargo, se permiten procedimientos almacenados extendidos. ¿Cómo es esto determinista? Si otra sesión modifica el estado de la base de datos, la salida de la función cambiará de todos modos.

Me estoy volviendo loco. Pensé que podría hacer que el almacenamiento en caché sea transparente para el usuario. es posible? No tengo los permisos para implementar procedimientos almacenados extendidos.

EDIT:

Esta limitación se encuentra todavía en 2008. No se puede llamar RAND, por amor de Dios!

La caché se implementaría en la base de datos. La memoria caché es cualquier almacén de datos utilizada para almacenar en caché ...

EDIT:

No hay casos en los que los mismos argumentos a una función dará lugar a resultados diferentes, fuera de los cambios en los datos subyacentes. Esta es una plataforma de BI, y los únicos cambios provienen de la ETL programada, en cuyo momento TRONCARE la tabla de la memoria caché.

Se trata de cálculos de series de tiempo intensivas de E/S, del orden de O (n^4). No tengo el mandato de cambiar la tabla o los índices subyacentes. Además, muchas de estas funciones utilizan las mismas funciones intermedias, y el almacenamiento en caché permite que se utilicen.

Las UDF no son realmente deterministas, a menos que representen cambios en el estado de la base de datos. ¿Cuál es el punto de? ¿Está el caché de SQL Server? (Irónico). Si SQL Server está almacenando en caché, debe estar expirando en los cambios a las tablas que están enlazadas al esquema. Si están enlazados a un esquema, ¿por qué no vincular tablas que la función modifica? Puedo ver por qué los procs no están permitidos, aunque eso es simplemente descuidado; solo esquemas vinculan procs. Y, por cierto, ¿por qué permitir los procesos almacenados extendidos? ¡¡No puedes rastrear lo que hacen para garantizar el determinismo !!! Argh !!!

EDIT:

Mi pregunta es: ¿Hay alguna manera de resultados de la función de caché en una forma que se pueden utilizar con pereza en una vista?

Answer 1

Determinístico significa que las mismas entradas devuelven el mismo resultado independientemente de la hora y la base de datos.

SQL Server (cualquier versión) no almacena en caché las UDF, creo que evitará llamar al UDF dos veces en una sola fila, pero eso es todo.

Un truco que he utilizado es (creo que he publicado aquí en SO):

Refactor la UDF si es posible por lo que hay efectivamente un subconjunto discreto útil de los valores devueltos para un conjunto dado de entradas. Para los cálculos numéricos, a veces se puede refactorizar la lógica para devolver un factor o tasa que se multiplica fuera de la UDF en lugar de multiplicar dentro de la UDF a partir de un valor pasado.

Llamar a la UDF sobre el conjunto de filas DISTINCT y almacenar en caché los resultados en una tabla temporal.Si solo llama al UDF con 100,000 tuplas de parámetros en un conjunto de filas de 17,000,000, esto es muy mucho más eficiente.

ÚNASE a la tabla temporal (básicamente convirtiendo de lógica basada en código a lógica basada en tabla) para obtener valores.

Esta tabla puede reutilizarse según sea necesario o incluso guardarse.

La adición a la tabla se puede hacer primero LEFT JOINing para encontrar entradas faltadas en caché.

Esto funciona tanto para UDF de una sola fila con valores de tabla como para UDF escalares. Lo uso principalmente para UDF con valores de tabla. Hay una revisión de SQL Server 2005 que se supone que trata el rendimiento de UDF. Estoy esperando que los DBAs lo prueben antes de implementarlo en producción.