¿LINQ a SQL versus procedimientos almacenados? [cerrado]
Eché un vistazo a la publicación "Guía para principiantes de LINQ" aquí en StackOverflow ( Guía para principiantes de LINQ ), pero tuve una pregunta de seguimiento:
Estamos a punto de poner en marcha un nuevo proyecto en el que casi todas nuestras operaciones de bases de datos serán recuperaciones de datos bastante simples (hay otro segmento del proyecto que ya escribe los datos). La mayoría de nuestros otros proyectos hasta este momento utilizan procedimientos almacenados para este tipo de cosas. Sin embargo, me gustaría aprovechar LINQ-to-SQL si tiene más sentido.
Entonces, la pregunta es la siguiente: para recuperaciones de datos simples, ¿qué enfoque es mejor, LINQ-to-SQL o procesos almacenados? ¿Alguna ventaja o desventaja específica?
Gracias.
Algunas ventajas de LINQ sobre sprocs:
- Seguridad de tipos : creo que todos entendemos esto.
- Abstracción : esto es especialmente cierto con LINQ-to-Entities . Esta abstracción también permite que el marco agregue mejoras adicionales que puede aprovechar fácilmente. PLINQ es un ejemplo de cómo agregar soporte de subprocesos múltiples a LINQ. Los cambios de código son mínimos para agregar este soporte. Sería MUCHO más difícil crear este código de acceso a datos que simplemente llama a sprocs.
- Soporte de depuración : puedo usar cualquier depurador .NET para depurar las consultas. Con sprocs, no puede depurar SQL fácilmente y esa experiencia está ligada en gran medida al proveedor de su base de datos (MS SQL Server proporciona un analizador de consultas, pero a menudo eso no es suficiente).
- Independiente del proveedor : LINQ funciona con muchas bases de datos y la cantidad de bases de datos compatibles solo aumentará. Los sprocs no siempre son portátiles entre bases de datos, ya sea debido a la sintaxis variable o al soporte de funciones (si es que la base de datos admite sprocs).
- Implementación : otros ya han mencionado esto, pero es más fácil implementar un solo ensamblaje que implementar un conjunto de sprocs. Esto también se relaciona con el punto 4.
- Más fácil : no es necesario aprender T-SQL para acceder a los datos, ni tampoco es necesario aprender la API de acceso a datos (por ejemplo, ADO.NET) necesaria para llamar a los sprocs. Esto está relacionado con los números 3 y 4.
Algunas desventajas de LINQ frente a sprocs:
- Tráfico de red : los sprocs solo necesitan serializar el nombre de sproc y los datos de los argumentos a través del cable mientras LINQ envía la consulta completa. Esto puede volverse realmente malo si las consultas son muy complejas. Sin embargo, la abstracción de LINQ permite a Microsoft mejorar esto con el tiempo.
- Menos flexible : Sprocs puede aprovechar al máximo el conjunto de características de una base de datos. LINQ tiende a ser más genérico en su soporte. Esto es común en cualquier tipo de lenguaje abstracto (por ejemplo, C# frente a ensamblador).
- Recompilar : si necesita realizar cambios en la forma en que accede a los datos, debe volver a compilar, versionar y volver a implementar su ensamblaje. En ocasiones, los sprocs pueden permitir que un DBA ajuste la rutina de acceso a datos sin necesidad de volver a implementar nada.
La seguridad y la capacidad de gestión son algo sobre lo que la gente también discute.
- Seguridad : por ejemplo, puede proteger sus datos confidenciales restringiendo el acceso a las tablas directamente y colocando ACL en los sprocs. Sin embargo, con LINQ aún puede restringir el acceso directo a las tablas y, en su lugar, colocar ACL en vistas de tablas actualizables para lograr un fin similar (suponiendo que su base de datos admita vistas actualizables).
- Manejabilidad : el uso de vistas también le brinda la ventaja de proteger su aplicación de cambios de esquema (como la normalización de tablas). Puede actualizar la vista sin necesidad de cambiar su código de acceso a datos.
Solía ser un gran tipo de sproc, pero estoy empezando a inclinarme hacia LINQ como una mejor alternativa en general. Si hay algunas áreas donde los sprocs son claramente mejores, entonces probablemente seguiré escribiendo un sproc pero accederé a él usando LINQ. :)
En general, soy partidario de poner todo en procedimientos almacenados, por todas las razones por las que los administradores de bases de datos han estado insistiendo durante años. En el caso de Linq, es cierto que no habrá diferencia de rendimiento con consultas CRUD simples.
Pero tenga en cuenta algunas cosas al tomar esta decisión: el uso de cualquier ORM lo vincula estrechamente con su modelo de datos. Un DBA no tiene libertad para realizar cambios en el modelo de datos sin obligarlo a cambiar su código compilado. Con los procedimientos almacenados, puede ocultar este tipo de cambios hasta cierto punto, ya que la lista de parámetros y los conjuntos de resultados devueltos por un procedimiento representan su contrato, y las entrañas se pueden cambiar, siempre y cuando ese contrato aún se cumpla. .
Y además, si Linq se utiliza para consultas más complejas, ajustar la base de datos se convierte en una tarea mucho más difícil. Cuando un procedimiento almacenado se ejecuta con lentitud, el DBA puede concentrarse totalmente en el código de forma aislada y tiene muchas opciones, solo para que el contrato aún se cumpla cuando haya terminado.
He visto muchos, muchos casos en los que problemas graves en una aplicación se solucionaron mediante cambios en el esquema y el código en los procedimientos almacenados sin ningún cambio en el código compilado implementado.
¿Quizás un enfoque híbrido sería bueno con Linq? Por supuesto, Linq se puede utilizar para llamar a procedimientos almacenados.
Linq a SQL.
El servidor SQL almacenará en caché los planes de consulta, por lo que no hay ganancia de rendimiento para los sprocs.
Sus declaraciones linq, por otro lado, serán lógicamente parte y probadas con su aplicación. Los sprocs siempre están un poco separados y son más difíciles de mantener y probar.
Si estuviera trabajando en una nueva aplicación desde cero en este momento, simplemente usaría Linq, sin problemas.
