Función frente a procedimiento almacenado en SQL Server

He estado aprendiendo funciones y procedimiento almacenado durante bastante tiempo, pero no sé por qué ni cuándo debería usar una función o un procedimiento almacenado. A mí me parecen iguales, tal vez porque soy un poco novato en eso.

¿Alguien puede decirme por qué?

preguntado el 24 de julio de 09 a las 16:07

¿Qué tal la velocidad? ¿Cuál ejecuta la misma consulta más rápido? -

Vale la pena mencionar que SP puede crear transacciones mientras que la función no:

21 Respuestas

Las funciones son valores calculados y no pueden realizar cambios ambientales permanentes para SQL Server (es decir, no INSERT or UPDATE declaraciones permitidas).

Una función se puede utilizar en línea en SQL declaraciones si devuelve un valor escalar o se puede unir si devuelve un conjunto de resultados.

Un punto que vale la pena destacar de los comentarios, que resumen la respuesta. Gracias a @Sean K Anderson:

Las funciones siguen la definición informática en el sentido de que DEBEN devolver un valor y no pueden alterar los datos que reciben como parámetros (los argumentos). Las funciones no pueden cambiar nada, deben tener al menos un parámetro y deben devolver un valor. Los procesos almacenados no tienen que tener un parámetro, pueden cambiar los objetos de la base de datos y no tienen que devolver un valor.

Respondido el 18 de junio de 20 a las 15:06

¿Básicamente no se permite DML? - David Blaine

Las funciones siguen la definición de informática en el sentido de que DEBEN devolver un valor y no pueden alterar los datos que reciben como parámetros (los argumentos). Las funciones no pueden cambiar nada, deben tener al menos un parámetro y deben devolver un valor. Los procesos almacenados no tienen que tener un parámetro, pueden cambiar los objetos de la base de datos y no tienen que devolver un valor. - Sean Anderson

De hecho, puede tener instrucciones INSERT, UPDATE y DELETE en una función para modificar las variables de la tabla local. - Ani

@Ani: puede crear instancias y modificar cualquier número de variables locales dentro de una función, sin embargo, no puede modificar nada fuera del alcance de la función. - MiPicazónChin

La función @SeanKAnderson "debe tener al menos un parámetro" no es verdadera. - liang

La diferencia entre SP y UDF se enumera a continuación:

Procedimiento almacenado (SP) Función (UDF - definida por el usuario)
SP puede devolver cero, uno o varios valores. La función debe devolver un solo valor (que puede ser un escalar o una tabla).
Podemos usar la transacción en SP. No podemos usar transacciones en UDF.
SP puede tener parámetro de entrada / salida. Solo parámetro de entrada.
Podemos llamar a la función desde SP. No podemos llamar a SP desde la función.
No podemos usar SP en la instrucción SELECT / WHERE / HAVING. Podemos usar UDF en la instrucción SELECT / WHERE / HAVING.
Podemos usar el manejo de excepciones usando el bloque Try-Catch en SP. No podemos usar el bloque Try-Catch en UDF.

Respondido el 25 de diciembre de 20 a las 23:12

Las funciones deben devolver un valor o un conjunto. - Rafareino

Esto llegó 3 años después, pero debería estar en la cima porque es legible y extenso. - dantethesmith

SP puede usar tanto tablas temporales como variables de tabla, mientras que UDF solo puede usar variables de tabla. Las variables de tabla, a su vez, no pueden utilizar índices. Se puede llamar a UDF en una APLICACIÓN CRUZADA a diferencia de SP - Ludovico Aubert

Las funciones y los procedimientos almacenados tienen fines distintos. Aunque no es la mejor analogía, las funciones se pueden ver literalmente como cualquier otra función que usaría en cualquier lenguaje de programación, pero los procesos almacenados son más como programas individuales o un script por lotes.

Las funciones normalmente tienen una salida y opcionalmente entradas. La salida se puede utilizar como entrada para otra función (un servidor SQL integrado como DATEDIFF, LEN, etc.) o como un predicado para una consulta SQL, por ejemplo, SELECT a, b, dbo.MyFunction(c) FROM table or SELECT a, b, c FROM table WHERE a = dbo.MyFunc(c).

Los procesos almacenados se utilizan para vincular consultas SQL en una transacción e interactuar con el mundo exterior. Los marcos como ADO.NET, etc. no pueden llamar a una función directamente, pero pueden llamar directamente a un proceso almacenado.

Sin embargo, las funciones tienen un peligro oculto: se pueden usar incorrectamente y causar problemas de rendimiento bastante desagradables: considere esta consulta:

SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)

Donde MyFunction se declara como:

CREATE FUNCTION MyFunction (@someValue INTEGER) RETURNS INTEGER
AS
BEGIN
   DECLARE @retval INTEGER

   SELECT localValue 
      FROM dbo.localToNationalMapTable
      WHERE nationalValue = @someValue

   RETURN @retval
END

Lo que sucede aquí es que se llama a la función MyFunction para cada fila de la tabla MyTable. Si MyTable tiene 1000 filas, entonces son otras 1000 consultas ad-hoc contra la base de datos. De manera similar, si se llama a la función cuando se especifica en la especificación de la columna, entonces se llamará a la función para cada fila devuelta por SELECT.

Por lo tanto, debe tener cuidado al escribir funciones. Si selecciona SELECT de una tabla en una función, debe preguntarse si se puede realizar mejor con un JOIN en el proceso almacenado principal o alguna otra construcción SQL (como CASE ... WHEN ... ELSE ... FINAL).

Respondido el 07 de Septiembre de 10 a las 14:09

¿Puede por favor explicar "Frameworks como ADO.NET, etc. no pueden llamar a una función directamente"? He ejecutado funciones con proveedores de datos ADO.NET sin problemas. - Ian Kemp

Debe llamar a una función a través de alguna instrucción SELECT; una función no se puede llamar como una pieza de código independiente por derecho propio; debe llamarse como parte de una declaración SQL más grande, incluso si esa declaración SQL no es nada más que SELECT * from dbo.MyTableValuedFunction(). Sprocs, por otro lado, se puede llamar directamente con ADO.NET configurando SqlCommand.CommandType a CommandType.StoredProcedure. - Chris J

Diferencias entre procedimientos almacenados y funciones definidas por el usuario:

  • Los procedimientos almacenados no se pueden utilizar en sentencias Select.
  • Los procedimientos almacenados admiten la resolución diferida de nombres.
  • Los procedimientos almacenados se utilizan generalmente para realizar la lógica empresarial.
  • Los procedimientos almacenados pueden devolver cualquier tipo de datos.
  • Los procedimientos almacenados pueden aceptar un mayor número de parámetros de entrada que las funciones definidas por el usuario. Los procedimientos almacenados pueden tener hasta 21,000 parámetros de entrada.
  • Los procedimientos almacenados pueden ejecutar SQL dinámico.
  • Los procedimientos almacenados admiten el manejo de errores.
  • Las funciones no deterministas se pueden utilizar en procedimientos almacenados.

  • Las funciones definidas por el usuario se pueden utilizar en sentencias Select.
  • Las funciones definidas por el usuario no admiten la resolución de nombres diferidos.
  • Las funciones definidas por el usuario se utilizan generalmente para cálculos.
  • Las funciones definidas por el usuario deben devolver un valor.
  • Las funciones definidas por el usuario no pueden devolver imágenes.
  • Las funciones definidas por el usuario aceptan un número menor de parámetros de entrada que los procedimientos almacenados. Las UDF pueden tener hasta 1,023 parámetros de entrada.
  • Las tablas temporales no se pueden utilizar en funciones definidas por el usuario.
  • Las funciones definidas por el usuario no pueden ejecutar SQL dinámico.
  • Las funciones definidas por el usuario no admiten el manejo de errores. RAISEERROR OR @@ERROR no se permiten en UDF.
  • Las funciones no deterministas no se pueden utilizar en UDF. Por ejemplo, GETDATE() no se puede utilizar en UDF.

contestado el 26 de mayo de 16 a las 15:05

Para citar a @curiousBoy a continuación, re. otra respuesta no acreditada (por @Ankit) (<- ¿ves cómo hice eso?;)): "Deberías haber dado la referencia de la fuente. Esto es de (blogs.msdn.microsoft.com/pradeepsvs/2014/10/08/…). ¡Por favor respete el trabajo que hacen los demás! "- tom

Este Blog se escribió desde el 8 de octubre de 2014 y esta respuesta se escribió desde el 2 de mayo de 2013 @Tom - kumar manish

@Code Rider: ¡Ah, mis disculpas! ¡No puedo creer que no me di cuenta de eso! Entonces, ¿el blog te copió (o alguien más que lo hizo) sin crédito? - tom

GETDATE() se puede utilizar en una función. El pivote en No determinista no es bueno. - RendimientoDBA

Escriba una función definida por el usuario cuando desee calcular y devolver un valor para usar en otras sentencias SQL; escribir un procedimiento almacenado cuando lo desee es agrupar un conjunto posiblemente complejo de sentencias SQL. ¡Estos son dos casos de uso bastante diferentes, después de todo!

Respondido 24 Jul 09, 20:07

existen diferentes tipos de funciones definidas por el usuario. Los escalares devuelven solo valores; otros tipos devuelven conjuntos de resultados. - Alaska

              STORE PROCEDURE                 FUNCTION (USER DEFINED FUNCTION)    
 * Procedure can return 0, single or   | * Function can return only single value   
   multiple values.                    |
                                       |
 * Procedure can have input, output    | * Function  can have only input 
   parameters.                         |   parameters.         
                                       |
 * Procedure cannot be called from     | * Functions can be called from 
   function.                           |   procedure.
                                       |
 * Procedure allows select as well as  | * Function allows only select statement 
   DML statement in it.                |   in it.
                                       |
 * Exception can be handled by         | * Try-catch block cannot be used in a 
   try-catch block in a procedure.     |   function.
                                       |
 * We can go for transaction management| * We can not go for transaction 
   in procedure.                       |   management in function.
                                       |
 * Procedure cannot be utilized in a   | * Function can be embedded in a select 
   select statement                    |   statement.
                                       |
 * Procedure can affect the state      | * Function can not affect the state 
   of database means it can perform    |   of database means it can not    
   CRUD operation on database.         |   perform CRUD operation on 
                                       |   database. 
                                       |
 * Procedure can use temporary tables. | * Function can not use 
                                       |   temporary tables. 
                                       |
 * Procedure can alter the server      | * Function can not alter the  
   environment parameters.             |   environment parameters.
                                       |   
 * Procedure can use when we want      | * Function can use when we want
   instead is to group a possibly-     |   to compute and return a value
   complex set of SQL statements.      |   for use in other SQL 
                                       |   statements.

Respondido 16 Oct 20, 10:10

Se puede llamar a UDF en una APLICACIÓN CRUZADA, a diferencia de SP - Ludovico Aubert

Diferencia básica

La función debe devolver un valor, pero en el procedimiento almacenado es opcional (el procedimiento puede devolver cero o n valores).

Las funciones solo pueden tener parámetros de entrada, mientras que los procedimientos pueden tener parámetros de entrada / salida.

La función toma un parámetro de entrada, es obligatorio, pero el procedimiento almacenado puede tomar n parámetros de entrada.

Las funciones se pueden llamar desde el procedimiento, mientras que los procedimientos no se pueden llamar desde la función.

Diferencia avanzada

El procedimiento permite la instrucción SELECT y DML (INSERT / UPDATE / DELETE) en él, mientras que la función solo permite la instrucción SELECT en él.

Los procedimientos no se pueden utilizar en una instrucción SELECT, mientras que la función se puede incrustar en una instrucción SELECT.

Los procedimientos almacenados no se pueden utilizar en las sentencias SQL en ninguna parte de la sección WHERE / HAVING / SELECT, mientras que Function sí lo es.

Las funciones que devuelven tablas pueden tratarse como otro conjunto de filas. Esto se puede usar en JOIN con otras tablas.

La función en línea se puede considerar como vistas que toman parámetros y se pueden usar en JOINs y otras operaciones de Rowset.

La excepción se puede manejar mediante el bloque try-catch en un procedimiento, mientras que el bloque try-catch no se puede usar en una función.

Podemos optar por la Gestión de transacciones en Procedimiento, mientras que no podemos ir en Función.

fuente

Respondido 24 ago 20, 06:08

Deberías haber dado la referencia de la fuente. Esto es de dotnet-tricks.com/Tutorial/sqlserver/… . ¡Respete el trabajo que hacen los demás! - chico curioso

No es una razón para no dar una referencia de fuente. ¡Puedes mencionarlo al final! - chico curioso

Re. "La función debe devolver un valor pero en el procedimiento almacenado es opcional ...": aclararía que: "Funciones debe: devolver uno y solo un valor (que debe hacerse a través del Returns palabra clave y debe ser un tipo escalar o de tabla), pero los procedimientos almacenados pueden opcionalmente regreso: a) 1 Int escriba el código de resultado a través del Return Declaración y / o b) 1+ Parámetros (incl. Cursor tipo) a través del Output palabra clave y / oc) 1+ conjuntos de filas a través de Select Declaraciones. Si solo se devuelve 1 conjunto de filas, se puede usar como el argumento "execute_statement" de una instrucción "Insertar en". "- tom

una función definida por el usuario es una herramienta importante disponible para un programador de servidor SQL. Puede usarlo en línea en una declaración SQL como esta

SELECT a, lookupValue(b), c FROM customers 

sin que importe lookupValue será una UDF. Este tipo de funcionalidad no es posible cuando se utiliza un procedimiento almacenado. Al mismo tiempo, no puede hacer ciertas cosas dentro de una UDF. Lo básico para recordar aquí es que las UDF:

  • no puede crear cambios permanentes
  • no puedo cambiar los datos

un procedimiento almacenado puede hacer esas cosas.

Para mí, el uso en línea de una UDF es el uso más importante de una UDF.

Respondido 09 Jul 13, 21:07

Procedimientos almacenados se utilizan como scripts. Ejecutan una serie de comandos por usted y puede programarlos para que se ejecuten en determinados momentos. Por lo general, ejecuta múltiples declaraciones DML como INSERT, UPDATE, DELETE, etc. o incluso SELECT.

clave se utilizan como métodos. Le pasa algo y devuelve un resultado. Debe ser pequeño y rápido, lo hace sobre la marcha. Usualmente se usa en una instrucción SELECT.

Respondido 07 Abr '20, 06:04

Este es un buen resumen de los dos, una manera rápida y sucia de pensar en ellos. - Eric Bishard

De hecho, un buen resumen. Otras respuestas se centran en la diferencia teórica de los dos, sin dejar de estar seguro de cuándo usar cuál en la práctica. - jf328

Procedimiento almacenado:

  • Es como un programa en miniatura en SQL Server.
  • Puede ser tan simple como una declaración de selección o tan complejo como un script largo que agrega, elimina, actualiza y / o lee datos de varias tablas en una base de datos.
  • (Puede implementar bucles y cursores, que le permiten trabajar con resultados más pequeños o operaciones fila por fila en los datos).
  • Debería llamarse usando EXEC or EXECUTE .
  • Devuelve variables de tabla, pero no podemos usar OUT parámetro.
  • Soporta transacciones.

Función:

  • No se puede utilizar para actualizar, eliminar o agregar registros a la base de datos.
  • Simplemente devuelve un valor único o un valor de tabla.
  • Solo se puede usar para seleccionar registros. Sin embargo, se puede llamar muy fácilmente desde SQL estándar, como:

    SELECT dbo.functionname('Parameter1')
    

    or

    SELECT Name, dbo.Functionname('Parameter1') FROM sysObjects
    
  • Para operaciones de selección simples y reutilizables, las funciones pueden simplificar el código. Solo ten cuidado de usar JOIN cláusulas en sus funciones. Si su función tiene un JOIN cláusula y la llama desde otra instrucción de selección que devuelve múltiples resultados, esa llamada de función JOIN esas mesas juntas para cada línea devuelta en el conjunto de resultados. Entonces, aunque pueden ser útiles para simplificar algo de lógica, también pueden ser un cuello de botella en el rendimiento si no se usan correctamente.

  • Devuelve los valores usando OUT parámetro.
  • No admite transacciones.

respondido 28 mar '18, 17:03

Función definida por el usuario.

  1. La función debe devolver un valor.
  2. Permitirá solo declaraciones Select, no nos permitirá usar declaraciones DML.
  3. Permitirá solo parámetros de entrada, no admite parámetros de salida.
  4. No nos permitirá usar bloques try-catch.
  5. No se permiten transacciones dentro de las funciones.
  6. Podemos usar solo variables de tabla, no permitirá usar tablas temporales.
  7. Los procedimientos almacenados no se pueden llamar desde una función.
  8. Las funciones se pueden llamar desde una instrucción de selección.
  9. Se puede utilizar una UDF en una cláusula de combinación como conjunto de resultados.

Procedimiento almacenado

  1. El procedimiento almacenado puede devolver valores o no.
  2. Puede tener declaraciones de selección, así como declaraciones DML como insertar, actualizar, eliminar, etc.
  3. Puede tener parámetros de entrada y salida.
  4. Para el manejo de excepciones, podemos usar bloques try catch.
  5. Puede utilizar transacciones dentro de procedimientos almacenados.
  6. Puede usar tanto variables de tabla como tabla temporal en ella.
  7. Los procedimientos almacenados pueden llamar a funciones.
  8. Los procedimientos no se pueden llamar desde Seleccionar / Dónde / Tener y así sucesivamente. La instrucción Execute / Exec se puede utilizar para llamar / ejecutar el procedimiento almacenado.
  9. Los procedimientos no se pueden utilizar en la cláusula Join

Respondido 29 Jul 19, 15:07

Para decidir cuándo usar lo que podrían ayudar los siguientes puntos:

  1. Los procedimientos almacenados no pueden devolver una variable de tabla donde una función puede hacer eso.

  2. Puede usar procedimientos almacenados para alterar los parámetros del entorno del servidor donde no puede usar funciones.

aplausos

Respondido 24 Jul 09, 20:07

Las funciones de SQL Server, como los cursores, están destinadas a ser utilizadas como su última arma. Tienen problemas de rendimiento y, por lo tanto, se debe evitar el uso de una función con valores de tabla tanto como sea posible. Hablar de rendimiento es hablar de una tabla con más de 1,000,000 de registros alojados en un servidor en un hardware de clase media; de lo contrario, no necesita preocuparse por el impacto en el rendimiento causado por las funciones.

  1. Nunca use una función para devolver un conjunto de resultados a un código externo (como ADO.Net)
  2. Utilice la combinación de vistas / procesos almacenados tanto como sea posible. Puede recuperarse de futuros problemas de rendimiento de crecimiento utilizando las sugerencias que le daría DTA (Database Tuning Adviser) (como vistas y estadísticas indexadas), ¡a veces!

para mayor referencia ver: http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html

Respondido el 09 de diciembre de 09 a las 20:12

Gracias. Escribí una función hoy para llamar dentro de una consulta para completar los valores de una columna. Execute se ejecutó durante más de 3 minutos antes de detenerlo. Descubrí una forma JOIN de hacerlo. Ejecutar terminado en 15 segundos. (El conjunto de datos fue de 3456 filas). Gran diferencia de rendimiento. - VISQL

editar: Ejecutar termina entre 15 y 50 segundos dependiendo de qué columna I "ORDEN POR" (El conjunto de datos era 3456 filas). Gran diferencia de rendimiento. - VISQL

La diferencia de rendimiento puede tener raíces en diferentes tipos de esas columnas por las que ordena el resultado. SQL Server funciona mucho mejor con números que con datos de caracteres. Puede usar DTA en esa consulta de 50 segundos y ver si puede generar algún tipo de sugerencias de estadísticas / índices para que la consulta se ejecute un poco más rápido. - Aquiles

No estoy seguro de que se hayan proporcionado pruebas suficientes para decir que debería ser un último recurso. Puede pensar en una función como una vista parametrizada en la que se puede seguir operando. Por ejemplo, desea unir clientes a los pedidos, pero solo para Michigan. Usted crea una función customerOrders (@StateCode) que solo se unirá al valor del cliente de un solo estado. Luego, puedo seguir operando en este conjunto como Seleccionar Nombre, Apellido, OrderTotal, StoreName de CustomerOrders ('MI') INNER JOIN Stores ON Stores.StoreID = Orders.StoreID WHERE OrderTotal> 100; Esto sería un problema con los SP, ya que debe realizar una copia temporal. - MPavlak

¿Cuántos registros tienes en esa tabla? Si su hardware lo maneja correctamente, no tendrá que preocuparse por elegir armas. Una cuchara puede hacer el trabajo cuando es lo suficientemente difícil como para romper una espada; ¡esta dureza se llama HARDWARE! - Aquiles

Comience con funciones que devuelvan un solo valor. Lo bueno es que puede poner código de uso frecuente en una función y devolverlo como una columna en un conjunto de resultados.

Luego, puede usar una función para una lista parametrizada de ciudades. dbo.GetCitiesIn ("NY") Eso devuelve una tabla que se puede usar como combinación.

Es una forma de organizar el código. Saber cuándo algo es reutilizable y cuándo es una pérdida de tiempo es algo que solo se gana a través de prueba y error y la experiencia.

Además, las funciones son una buena idea en SQL Server. Son más rápidos y pueden ser bastante potentes. Selecciones en línea y directas. Cuidado de no abusar.

Respondido el 16 de Septiembre de 13 a las 21:09

Aquí hay una razón práctica para preferir las funciones a los procedimientos almacenados. Si tiene un procedimiento almacenado que necesita los resultados de otro procedimiento almacenado, debe usar una instrucción insert-exec. Esto significa que debe crear una tabla temporal y usar una exec instrucción para insertar los resultados del procedimiento almacenado en la tabla temporal. Está desordenado. Un problema con esto es que insert-execs no se pueden anidar.

Si está atascado con procedimientos almacenados que llaman a otros procedimientos almacenados, puede encontrarse con esto. Si el procedimiento almacenado anidado simplemente devuelve un conjunto de datos, se puede reemplazar con una función con valores de tabla y ya no obtendrá este error.

(Esta es otra razón por la que debemos mantener la lógica empresarial fuera de la base de datos.)

contestado el 31 de mayo de 16 a las 18:05

Me doy cuenta de que esta es una pregunta muy antigua, pero no veo un aspecto crucial mencionado en ninguna de las respuestas: alinearse en el plan de consulta.

Las funciones pueden ser ...

  1. Escalar:

    CREATE FUNCTION ... RETURNS scalar_type AS BEGIN ... END

  2. Valor de tabla de declaraciones múltiples:

    CREATE FUNCTION ... RETURNS @r TABLE(...) AS BEGIN ... END

  3. Valor de tabla en línea:

    CREATE FUNCTION ... RETURNS TABLE AS RETURN SELECT ...

El optimizador de consultas trata el tercer tipo (con valores de tabla en línea) esencialmente como vistas (parametrizadas), lo que significa que hacer referencia a la función desde su consulta es similar a copiar y pegar el cuerpo SQL de la función (sin realmente copiar y pegar), lo que lleva a a los siguientes beneficios:

  • El planificador de consultas puede optimizar la ejecución de la función en línea tal como lo haría con cualquier otra subconsulta (por ejemplo, eliminar columnas no utilizadas, empujar predicados hacia abajo, elegir diferentes estrategias JOIN, etc.).
  • La combinación de varias funciones en línea no requiere materializar el resultado de la primera antes de pasarla a la siguiente.

Lo anterior puede generar ahorros de rendimiento potencialmente significativos, especialmente cuando se combinan múltiples niveles de funciones.


NOTA: Parece que SQL Server 2019 introducirá algún tipo de alineación de función escalar también.

Respondido el 18 de enero de 19 a las 06:01

  • Es obligatorio que la función devuelva un valor mientras que no sea para el procedimiento almacenado.
  • Seleccione declaraciones solo aceptadas en UDF, mientras que las declaraciones DML no son necesarias.
  • El procedimiento almacenado acepta cualquier declaración, así como declaraciones DML.
  • UDF solo permite entradas y no salidas.
  • El procedimiento almacenado permite tanto entradas como salidas.
  • Los bloques de captura no se pueden usar en UDF pero se pueden usar en un procedimiento almacenado.
  • No se permiten transacciones en funciones en UDF pero sí en procedimiento almacenado.
  • Solo se pueden usar variables de tabla en UDF y no tablas temporales.
  • El procedimiento almacenado permite tanto variables de tabla como tablas temporales.
  • UDF no permite llamar a procedimientos almacenados desde funciones, mientras que los procedimientos almacenados permiten llamar a funciones.
  • UDF se usa en la cláusula de combinación, mientras que los procedimientos almacenados no se pueden usar en la cláusula de combinación.
  • El procedimiento almacenado siempre permitirá volver a cero. UDF, por el contrario, tiene valores que deben regresar a un punto predeterminado.

Respondido el 11 de diciembre de 13 a las 16:12

Procedimiento almacenado de msql vs función:

enter image description here

Respondido el 16 de junio de 20 a las 22:06

  • Las funciones se pueden usar en una instrucción de selección donde los procedimientos no pueden.

  • El procedimiento almacenado toma tanto parámetros de entrada como de salida, pero Funciones solo toma parámetros de entrada.

  • Las funciones no pueden devolver valores de tipo text, ntext, image & timestamps donde los procedimientos pueden hacerlo.

  • Las funciones se pueden utilizar como tipos de datos definidos por el usuario en la tabla de creación, pero los procedimientos no.

*** Por ejemplo: -crear table <tablename>(name varchar(10),salary getsal(name))

Aquí getsal es una función definida por el usuario que devuelve un tipo de salario, cuando se crea la tabla no se asigna almacenamiento para el tipo de salario, y la función getsal tampoco se ejecuta, pero cuando buscamos algunos valores de esta tabla, la función getsal se ejecuta y el return Type se devuelve como conjunto de resultados.

Respondido el 16 de enero de 14 a las 14:01

Generalmente, el uso de procedimientos almacenados es mejor para los resultados. Por ejemplo, en versiones anteriores de SQL Server, si coloca la función en condición JOIN, la estimación de cardinalidad es 1 (antes de SQL 2012) y 100 (después de SQL 2012 y antes de SQL 2017) y el motor puede generar un plan de ejecución incorrecto.

Además, si lo pone en la cláusula WHERE, el motor SQL puede generar un plan de ejecución incorrecto.

Con SQL 2017, Microsoft introdujo la función llamada ejecución intercalada para producir una estimación más precisa, pero el procedimiento almacenado sigue siendo la mejor solución.

Para más detalles mira el siguiente artículo de Joe Sack https://techcommunity.microsoft.com/t5/sql-server/introducing-interleaved-execution-for-multi-statement-table/ba-p/385417

Respondido 16 Jul 20, 22:07

En SQL Server, las funciones y el procedimiento almacenado son dos tipos diferentes de entidades.

Función: En la base de datos de SQL Server, las funciones se utilizan para realizar algunas acciones y la acción devuelve un resultado inmediatamente. Las funciones son de dos tipos:

  1. Definido por el sistema

  2. definido por el usuario

Procedimientos almacenados: En SQL Server, los procedimientos almacenados se almacenan en el servidor y pueden devolver cero, valores únicos y múltiples. Los procedimientos almacenados son de dos tipos:

  1. Procedimientos almacenados del sistema
  2. Procedimientos definidos por el usuario

Respondido el 17 de diciembre de 15 a las 07:12

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.