parametros - Funciones vs procedimientos en Oracle
procedimiento almacenado oracle select (6)
¿Alguien puede explicar cuál es la principal diferencia entre funciones y procedimientos en Oracle? ¿Por qué debo usar procedimientos si puedo hacer todo con las funciones?
- Si no puedo llamar al procedimiento en la declaración SQL, vale, escribiré una función para hacer el mismo trabajo.
- Los procedimientos no devuelven valores, vale, devolveré solo sql% rowcount o 1 (éxito), 0 (excepción) después de cualquier operación dml
- Tanto los procedimientos como las funciones pueden pasar variables al entorno de llamada a través de los parámetros OUT / IN OUT
Escuché que la principal diferencia está en el rendimiento, "los procedimientos son más rápidos que las funciones". Pero sin ningún detalle.
Gracias por adelantado.
El procedimiento puede o no devolver el valor pero las funciones devuelven valor.
procedimiento use el parámetro returnvalue purpose pero function returnstatment provide.
- procedimiento utilizado manipulación de datos pero función uso cálculo de datos.
- el tiempo de ejecución del procedimiento no utiliza la instrucción select, pero la función usa la instrucción select. Estas son las principales diferencias de eso.
Casi nunca hay una diferencia de rendimiento entre los procedimientos y las funciones.
En algunos casos extremadamente raros:
- Un procedimiento
IN OUT
argumentoIN OUT
es más rápido que un retorno de función, cuando se habilita la alineación. - Un procedimiento
IN OUT
argumentoIN OUT
es más lento que un retorno de función, cuando la línea está desactivada.
Código de prueba
--Run one of these to set optimization level:
--alter session set plsql_optimize_level=0;
--alter session set plsql_optimize_level=1;
--alter session set plsql_optimize_level=2;
--alter session set plsql_optimize_level=3;
--Run this to compare times. Move the comment to enable the procedure or the function.
declare
v_result varchar2(4000);
procedure test_procedure(p_result in out varchar2) is
begin
p_result := ''0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789'';
end;
function test_function return varchar2 is
begin
return ''0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789'';
end;
begin
for i in 1 .. 10000000 loop
--Comment out one of these lines to change the test.
--test_procedure(v_result);
v_result := test_function;
end loop;
end;
/
Resultados
Inlining enabled: PLSQL_OPTIMIZE_LEVEL = 2 (default) or 3
Function run time in seconds: 2.839, 2.933, 2.979
Procedure run time in seconds: 1.685, 1.700, 1.762
Inlining disabled: PLSQL_OPTIMIZE_LEVEL = 0 or 1
Function run time in seconds: 5.164, 4.967, 5.632
Procedure run time in seconds: 6.1, 6.006, 6.037
El código anterior es trivial y quizás esté sujeto a otras optimizaciones. Pero he visto resultados similares con el código de producción.
Por qué la diferencia no importa
No mire la prueba anterior y piense que "¡un procedimiento funciona dos veces más rápido que una función!". Sí, la sobrecarga de una función es casi el doble que la sobrecarga de un procedimiento. Pero de cualquier forma, la sobrecarga es irrelevantemente pequeña.
La clave del rendimiento de la base de datos es hacer todo el trabajo posible en sentencias de SQL, en lotes. Si un programa llama a una función o procedimiento diez millones de veces por segundo, entonces ese programa tiene serios problemas de diseño.
Como sé, el procedimiento Store se compila una vez y se puede llamar una y otra vez sin compilar de nuevo. Pero la función se compila cada vez que se llama. Por lo tanto, el procedimiento de almacenamiento mejora el rendimiento de la función.
Creo que la mayor diferencia es:
Las funciones no pueden contener DML Statemnt mientras que los procedimientos sí pueden. por ejemplo, como Actualizar e Insertar.
si estoy equivocado, corrígeme
Cambio de estado vs no cambio de estado
Además de la respuesta de Romo Daneghyan , siempre he visto la diferencia como su comportamiento en el estado del programa. Eso es, conceptualmente ,
- Los procedimientos pueden cambiar algún estado, ya sea de los parámetros o del entorno (por ejemplo, datos en tablas, etc.).
- Las funciones no cambian de estado, y es de esperar que llamar a una función en particular no modifique ningún dato / estado. (Es decir, el concepto que subyace a la programación funcional )
Es decir, si llamaras a una función llamada generateId(...)
, esperarías que solo hiciera algunos cálculos y devuelva un valor. Pero al llamar a un procedimiento generateId ...
, puede esperar que cambie los valores en algunas tablas.
Por supuesto, parece que en Oracle, así como en muchos idiomas, esto no se aplica y no se aplica, así que tal vez soy solo yo.
La diferencia es: una función debe devolver un valor (de cualquier tipo) por definición predeterminada, mientras que en el caso de un procedimiento, debe usar parámetros como OUT
o IN OUT
para obtener los resultados. Puede usar una función en un SQL
normal donde no puede usar un procedimiento en SQL
de SQL
.
Algunas diferencias entre funciones y procedimientos
Una función siempre devuelve un valor utilizando la instrucción return mientras que un procedimiento puede devolver uno o más valores a través de parámetros o puede que no regrese en absoluto. Aunque los parámetros
OUT
todavía se pueden usar en funciones, no son aconsejables ni tampoco hay casos donde uno pueda encuentra una necesidad de hacerlo El uso del parámetroOUT
restringe el uso de una función en una instrucción SQL.Las funciones se pueden usar en sentencias de SQL típicas como
SELECT
,INSERT
,UPDATE
,DELETE
,MERGE
, mientras que los procedimientos no pueden.Las funciones se usan normalmente para cálculos donde los procedimientos se usan normalmente para ejecutar la lógica comercial.
Oracle proporciona la provisión de crear " Índices basados en funciones " para mejorar el rendimiento de la siguiente instrucción SQL. Esto se aplica cuando se realiza la función en una columna indexada en la cláusula where de una consulta.
Más información sobre funciones vs. Procedimientos here y here .