Funciones definidas por el usuario: ¿son una mala práctica de codificación?

Question

Estoy escribiendo informes con conjuntos de datos bastante complejos, muchas combinaciones. Para simplificar las cosas, y debido a que básicamente soy un desarrollador de OO, he estado escribiendo pequeñas funciones (generalmente escalares) para hacer el trabajo que podría hacerse al unirme a una subconsulta. Este tipo de cosas:

SELECT 
    x.Name, x.userId, 
    ... [more columns and joins] 
    dbo.CountOrders(x.userId) 
FROM Customers x 
WHERE ... 

¿Es esta una buena práctica? ¿Poco riguroso? ¿Lento? ¿Debo escribir regular T-SQL para hacer esto?

Answer 1

Casi nunca tendré una UDF escalar que tenga acceso a los datos.

Las UDF escalares no pueden expandirse por el optimizador y deben evaluarse con RBAR. Está bastante bien establecido que esta no es una buena idea.

Algunos ejemplos de lectura.

• TSQL Scalar functions are evil.
• Scalar functions, inlining, and performance: An entertaining title for a boring post
• Higly Voted Connect Item

Answer 2

En mi opinión y por mi experiencia, las funciones en línea no son necesariamente malas. A veces enfrento una tarea que no podría lograr sin usar funciones. Si reutiliza la misma rutina una y otra vez en sus procedimientos almacenados, entonces, al igual que en el viejo OOP, crea una función y la usa. Pero solo por el código limpio y corto, no recomendaría el uso de funciones, si se usa una sola vez. El rendimiento o la mejora proviene de la indexación de tablas y el mantenimiento de índices. Siempre que los índices se creen y mantengan correctamente, las funciones en línea son tan buenas como escribir una declaración SQL sencilla.

Answer 3

No creo que haya mucho daño al hacer cálculos de llamadas de función en SQL, siempre que quede claro dónde se están haciendo a los usuarios de la tabla. Todo lo que ha hecho aquí es hacer un acceso directo a una subconsulta. Sin embargo, nunca hago esto con mis consultas de acceso primarias ya que las personas comienzan a "dar por hecho" este tipo de cálculos.

Si descubro que estoy haciendo esto de manera repetitiva, me parece más valioso hacer una tabla de apartamiento que contenga este tipo de información en una forma precalculada y luego usar activadores para mantenerla actualizada. Un ejemplo de esto es una base de datos en la que acumulo los datos del resumen financiero de los artículos de línea de la factura al nivel de oferta, luego al nivel de presentación (que tiene varias cotizaciones) y luego al nivel de política (que tiene múltiples árboles de múltiples portadores).

Resulta que la mayoría de las consultas realmente necesitan los datos en el nivel de la política. Mediante el uso de desencadenantes y tablas de resumen, aceleré algunas consultas críticas literalmente en dos órdenes de magnitud simplemente porque el trabajo ya estaba hecho, al tiempo que disminuía el rendimiento de un cambio guardado en una cantidad sin importancia. Entonces, si te encuentras realizando muchas consultas de resumen, piensa en una forma de evitar el trabajo ... pero para casos simples, creo que las llamadas en línea a las funciones están bien.