Cuál es el mejor procedimiento de vista o almacenado en el servidor sql para el propósito de acceso a datos

Question

A menudo uso el procedimiento almacenado para el propósito de acceso a datos pero no sé cuál es la mejor vista o SP.

El procedimiento almacenado y las vistas se compilan y el plan de ejecución se guarda en la base de datos. Así que díganme cuál es el mejor para el acceso a los datos y por qué es mejor enumerar el motivo por favor.

Busco en google para saber cuál es el mejor pero no obtuve la respuesta esperada.

Answer 1

Las vistas y los procedimientos almacenados sirven para fines completamente diferentes. Las vistas son una forma conveniente de referirse a un conjunto relacional complejo (como el que se une a muchas tablas) como una tabla plana sin forzar realmente la manifestación de los datos. Utiliza una vista para limpiar el código SQL. Sus procedimientos almacenados podrían llamar vistas. Las vistas se utilizan a menudo para el control de permisos. Puede otorgar a los usuarios de bases de datos acceso a una vista sin otorgarles acceso a las tablas subyacentes. Esto otorga al usuario permisos de nivel de columna en las columnas de la vista, que es un método mucho más granular para el control de permisos que otorgar acceso a tablas completas.

Los procedimientos almacenados se utilizan para mantener juntas la funcionalidad de uso frecuente como una unidad. Para ser honesto, los SP pierden el favor de muchos programadores. Si bien tiene razón en que los SP tienen sus planes de ejecución en caché, el SQL dinámico ha tenido el almacenamiento en caché del plan de ejecución desde SQL Server 2000 (creo que esa es la versión correcta). La única ganancia de velocidad que obtendrás yendo con los SP es enviando menos datos a través de la red, y eso será extremadamente mínimo. Los SP tienden a hacer que el código sea más frágil y requieren cambios en el DB para que ocurra cuando los cambios en la aplicación realmente no lo justifiquen. Por ejemplo, si solo desea cambiar las condiciones para las filas que está seleccionando. Con los SP, tendrá que transferir los cambios a la aplicación y al código de la base de datos. Si está utilizando SQL dinámico o una herramienta ORM, solo necesita hacer cambios en la aplicación que simplifica la implementación. Existe absolutamente un momento y lugar para los SP, pero no necesitan ser su único método para interactuar con la base de datos.

Además, si le preocupa el rendimiento, puede materializar vistas, lo que reduce la necesidad de consultar repetidamente las tablas subyacentes. Esto podría mejorar enormemente su rendimiento si siente la necesidad de agregar la sobrecarga adicional en las inserciones/actualizaciones que inducen las vistas materializadas.

Answer 2

Para acelerar la consulta, necesita índices definidos correctamente en la tabla. Dentro de un procedimiento almacenado puede usar parámetros, implementar su propia lógica, sin embargo dentro de una vista no puede

Porque: Una vez que se compila el procedimiento, hace su plan de ejecución y lo usa para cada vez que lo llamamos incluso cuando insertamos datos nuevos en la tabla relacionada también, hasta que hagamos cualquier cambio en el código de procedimiento.

Verifique los nuevos datos actualizados cada vez que lo llame.

Puede hacer todo el manejo de transacciones, etc. con SP.

Answer 3

No estoy de acuerdo con Jared Harding cuando se trata de procedimientos almacenados que hacen que las actualizaciones de las aplicaciones sean más difíciles. Es mucho más fácil actualizar un procedimiento almacenado que actualizar el código de la aplicación, que podría necesitar ser recompilado y requerirle que expulse a los usuarios del sistema para realizar una actualización. Si escribe todo su SQL en procedimientos almacenados, probablemente solo tendrá que actualizar la aplicación la mitad de las veces que lo haría de otra manera. Y un procedimiento almacenado se puede actualizar sin interrupción para los usuarios.

Recomiendo encarecidamente el uso de procedimientos almacenados sobre vistas o SQL escritos dentro del código de la aplicación.Con procedimientos almacenados parametrizados que usan SQL dinámico creado como una cadena y llamado con la función segura sp_executesql, puede escribir un único procedimiento almacenado para seleccionar datos que se pueden usar en múltiples aplicaciones e informes. Prácticamente no es necesario utilizar una vista a menos que realmente necesite bloquear permisos en tablas subyacentes. Es mucho mejor crear su consulta SELECT básica dentro de un procedimiento almacenado y luego usar opciones de parámetros para cambiar la forma en que se filtran los resultados. Por ejemplo, cada parámetro puede agregar una línea diferente a su cláusula WHERE. Al no pasar ningún parámetro, recupera el conjunto de registros sin filtrar completo. Tan pronto como necesite filtrar sus resultados por un campo diferente, solo necesita agregar un parámetro y una línea de código en ese procedimiento, y luego tener cualquier aplicación que necesite hacer uso de pasarlo en el parámetro. Al establecer por defecto los parámetros del procedimiento almacenado en nulo, no tiene que cambiar ninguna aplicación que llame a ese procedimiento almacenado para otros fines.