¿LINQ a SQL versus procedimientos almacenados?[cerrado]

https://stackoverflow.com/questions/14530

08-06-2019
|

Pregunta

Eché un vistazo a la publicación "Guía para principiantes de LINQ" aquí en StackOverflow (Guía para principiantes de LINQ), pero tenía 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 esta:Para recuperaciones de datos simples, ¿qué enfoque es mejor, LINQ-to-SQL o procesos almacenados?¿Alguna ventaja o desventaja específica?

Gracias.

Solución

Algunas ventajas de LINQ sobre sprocs:

Tipo de seguridad:Creo que todos entendemos esto.
Abstracción:Esto es especialmente cierto con LINQ a entidades.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).
Despliegue: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 datos, ni tampoco es necesario aprender la API de acceso a datos (p. ej.ADO.NET) necesario 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:sprocs solo necesita 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 abstracción lingüística (p. ej.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.Los sprocs pueden a veces 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 las ACL en una tabla actualizable. puntos de vista 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.:)

Otros consejos

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 acopla estrechamente a 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.

Para la recuperación de datos básicos, elegiría Linq sin dudarlo.

Desde que me mudé a Linq, encontré las siguientes ventajas:

Depurar mi DAL nunca ha sido tan fácil.
La seguridad del tiempo de compilación cuando cambia su esquema no tiene precio.
La implementación es más fácil porque todo está compilado en archivos DLL.No más gestión de scripts de implementación.
Debido a que Linq puede admitir consultas de cualquier cosa que implemente la interfaz IQueryable, podrá usar la misma sintaxis para consultar XML, objetos y cualquier otra fuente de datos sin tener que aprender una nueva sintaxis.

LINQ inflará el caché de procedimientos

Si una aplicación utiliza LINQ to SQL y las consultas implican el uso de cadenas que pueden tener una longitud muy variable, la caché de procedimientos de SQL Server se inflará con una versión de la consulta para cada longitud de cadena posible.Por ejemplo, considere las siguientes consultas muy simples creadas en la tabla Person.AddressTypes en la base de datos AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Si se ejecutan ambas consultas, veremos dos entradas en la caché de procedimientos de SQL Server:Uno vinculado con NVARCHAR(7) y el otro con NVARCHAR(11).Ahora imagine si hubiera cientos o miles de cadenas de entrada diferentes, todas con diferentes longitudes.La caché de procedimientos se llenaría innecesariamente con todo tipo de planes diferentes para exactamente la misma consulta.

Más aquí: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Creo que el argumento a favor de LINQ parece provenir de personas que no tienen experiencia en el desarrollo de bases de datos (en general).

Especialmente si se utiliza un producto como VS DB Pro o Team Suite, muchos de los argumentos presentados aquí no se aplican, por ejemplo:

Más difícil de mantener y probar:VS proporciona verificación completa de sintaxis, verificación de estilo, verificación de referencias y restricciones, y más.También proporciona capacidades completas de pruebas unitarias y herramientas de refactorización.

LINQ hace que las verdaderas pruebas unitarias sean imposibles ya que (en mi opinión) no pasa la prueba ACID.

La depuración es más fácil en LINQ:¿Por qué?VS permite un acceso completo desde el código administrado y la depuración periódica de los SP.

Compilado en una única DLL en lugar de scripts de implementación:Una vez más, VS viene al rescate, donde puede crear e implementar bases de datos completas o realizar cambios incrementales seguros para los datos.

No es necesario aprender TSQL con LINQ:No, no es así, pero tienes que aprender LINQ. ¿Dónde está el beneficio?

Realmente no veo esto como un beneficio.Ser capaz de cambiar algo de forma aislada puede sonar bien en teoría, pero el hecho de que los cambios cumplan un contrato no significa que se devuelvan los resultados correctos.Para poder determinar cuáles son los resultados correctos, necesita contexto y ese contexto lo obtiene del código de llamada.

Um, las aplicaciones débilmente acopladas son el objetivo final de todos los buenos programadores, ya que realmente aumentan la flexibilidad.Ser capaz de cambiar cosas de forma aislada es fantástico, y son las pruebas unitarias las que garantizarán que siga arrojando resultados adecuados.

Antes de que todos se enojen, creo que LINQ tiene su lugar y tiene un gran futuro.Pero para aplicaciones complejas y con uso intensivo de datos, no creo que esté listo para reemplazar a los procedimientos almacenados.Esta fue una opinión de la que me hizo eco un MVP de TechEd este año (permanecerán en el anonimato).

EDITAR:El lado del procedimiento almacenado de LINQ to SQL es algo sobre lo que todavía necesito leer más; dependiendo de lo que encuentre, puedo modificar mi diatriba anterior;)

LINQ es nuevo y tiene su lugar.LINQ no se inventó para reemplazar el procedimiento almacenado.

Aquí me centraré en algunos mitos y CONTRAS del rendimiento, sólo para "LINQ to SQL", por supuesto que podría estar totalmente equivocado ;-)

(1) La gente dice que la declaración LINQ puede "almacenarse en caché" en el servidor SQL, por lo que no pierde rendimiento.Parcialmente cierto."LINQ to SQL" en realidad es el tiempo de ejecución que traduce la sintaxis de LINQ a una declaración TSQL.Entonces, desde la perspectiva del rendimiento, una declaración SQL ADO.NET codificada no tiene diferencia con LINQ.

(2) Como ejemplo, una interfaz de usuario de servicio al cliente tiene una función de "transferencia de cuenta".esta función en sí misma podría actualizar 10 tablas de base de datos y devolver algunos mensajes de una sola vez.Con LINQ, debe crear un conjunto de declaraciones y enviarlas como un solo lote al servidor SQL.el rendimiento de este lote LINQ->TSQL traducido difícilmente puede igualar el procedimiento almacenado.¿Razón?Debido a que puede modificar la unidad más pequeña de la declaración en el procedimiento almacenado mediante el generador de perfiles SQL integrado y la herramienta de plan de ejecución, no puede hacer esto en LINQ.

El punto es que, cuando se habla de una sola tabla de base de datos y un pequeño conjunto de datos CRUD, LINQ es tan rápido como SP.Pero para una lógica mucho más complicada, el rendimiento del procedimiento almacenado es más modificable.

(3) "LINQ to SQL" hace que los novatos presenten fácilmente acaparadores de rendimiento.Cualquier experto en TSQL puede indicarle cuándo no usar CURSOR (Básicamente, no debería usar CURSOR en TSQL en la mayoría de los casos).Con LINQ y el encantador bucle "foreach" con consulta, es muy fácil para un novato escribir este código:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Puedes ver que este código sencillo y decente es muy atractivo.Pero en el fondo, el tiempo de ejecución de .NET simplemente traduce esto en un lote de actualización.Si solo hay 500 líneas, este es un lote TSQL de 500 líneas;Si hay millones de líneas, esto es un éxito.Por supuesto, un usuario experimentado no utilizará esta forma para hacer este trabajo, pero el punto es que es muy fácil caer de esta manera.

El mejor código es no tener código, y con los procedimientos almacenados tienes que escribir al menos algo de código en la base de datos y código en la aplicación para llamarlo, mientras que con LINQ to SQL o LINQ to Entities, no tienes que escribir ningún código adicional. código más allá de cualquier otra consulta LINQ además de crear una instancia de un objeto de contexto.

LINQ definitivamente tiene su lugar en bases de datos de aplicaciones específicas y en pequeñas empresas.

Pero en una gran empresa, donde las bases de datos centrales sirven como centro de datos comunes para muchas aplicaciones, necesitamos abstracción.Necesitamos gestionar de forma centralizada la seguridad y mostrar historiales de acceso.Necesitamos poder hacer análisis de impacto:Si hago un pequeño cambio en el modelo de datos para satisfacer una nueva necesidad empresarial, ¿qué consultas deben cambiarse y qué aplicaciones deben volver a probarse?Las vistas y los procedimientos almacenados me dan eso.Si LINQ puede hacer todo eso y hacer que nuestros programadores sean más productivos, lo agradeceré. ¿Alguien tiene experiencia usándolo en este tipo de entorno?

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 el conjunto de resultados que regresan de un procedimiento representan su contrato, y las entrañas se pueden cambiar, siempre y cuando ese contrato aún se cumpla .

Realmente no veo esto como un beneficio.Ser capaz de cambiar algo de forma aislada puede sonar bien en teoría, pero el hecho de que los cambios cumplan un contrato no significa que se devuelvan los resultados correctos.Para poder determinar cuáles son los resultados correctos, necesita contexto y ese contexto lo obtiene del código de llamada.

En mi humilde opinión, RAD = LINQ, RUP = Procesos almacenados.Trabajé para una gran empresa Fortune 500 durante muchos años, en muchos niveles, incluida la gestión, y, francamente, nunca contrataría desarrolladores de RUP para realizar desarrollo RAD.Están tan aislados que su conocimiento es muy limitado sobre qué hacer en otros niveles del proceso.Con un entorno aislado, tiene sentido darle a los DBA control sobre los datos a través de puntos de entrada muy específicos, porque otros, francamente, no conocen las mejores maneras de lograr la gestión de datos.

Pero las grandes empresas se mueven penosamente lento en el ámbito del desarrollo, y esto es extremadamente costoso.Hay ocasiones en las que es necesario avanzar más rápido para ahorrar tiempo y dinero, y LINQ ofrece eso y más con creces.

A veces pienso que los DBA tienen prejuicios contra LINQ porque sienten que amenaza su seguridad laboral.Pero así es la naturaleza de la bestia, damas y caballeros.

Creo que necesitas usar procs para cualquier cosa real.

A) Escribir toda su lógica en linq significa que su base de datos es menos útil porque solo su aplicación puede consumirla.

B) De todos modos, no estoy convencido de que el modelado de objetos sea mejor que el modelado relacional.

C) Probar y desarrollar un procedimiento almacenado en SQL es muchísimo más rápido que un ciclo de edición de compilación en cualquier entorno de Visual Studio.Simplemente edita, presiona F5 y presiona seleccionar y listo.

D) Es más fácil administrar e implementar procedimientos almacenados que ensamblajes.simplemente coloca el archivo en el servidor y presiona F5...

E) Linq to sql todavía escribe código deficiente en momentos en los que no lo esperas.

Honestamente, creo que lo último sería que MS aumentara t-sql para que pueda realizar una proyección de unión implícitamente como lo hace linq.t-sql debería saber si desea hacer order.lineitems.part, por ejemplo.

LINQ no prohíbe el uso de procedimientos almacenados.He usado el modo mixto con LINQ-SQL y LINQ-procedimiento almacenado.Personalmente, me alegro de no tener que escribir los procesos almacenados... pwet-tu.

Además, está la cuestión de una posible reversión de 2.0.Créame, me ha pasado un par de veces, así que estoy seguro de que a otros les ha pasado.

También estoy de acuerdo en que la abstracción es la mejor.Además, el propósito original de un ORM es hacer que RDBMS coincida bien con los conceptos OO.Sin embargo, si todo funcionaba bien antes de LINQ al tener que desviarse un poco de los conceptos OO, entonces al diablo con ellos.Los conceptos y la realidad no siempre encajan bien.No hay lugar para fanáticos militantes en TI.

Supongo que te refieres a Linq To Sql

Para cualquier comando CRUD, es fácil perfilar el rendimiento de un procedimiento almacenado vs.cualquier tecnología.En este caso cualquier diferencia entre ambos será insignificante.Intente crear perfiles para un objeto de campo de 5 (tipos simples) en más de 100.000 consultas seleccionadas para descubrir si hay una diferencia real.

Por otro lado, el verdadero factor decisivo será la cuestión de si se siente cómodo poniendo su lógica empresarial en su base de datos o no, lo cual es un argumento en contra de los procedimientos almacenados.

Según los gurús, defino LINQ como motocicleta y SP como automóvil.Si desea realizar un viaje corto y solo tiene pasajeros pequeños (en este caso 2), hágalo con elegancia con LINQ.Pero si quieres viajar y tener una banda grande, creo que deberías elegir SP.

En conclusión, elegir entre moto o coche depende de tu ruta (negocio), duración (tiempo) y pasajeros (datos).

Espero que te ayude, puede que me equivoque.:D

Todas estas respuestas que se inclinan hacia LINQ hablan principalmente de FACILIDAD DE DESARROLLO, que está más o menos relacionada con la mala calidad de la codificación o la pereza en la codificación.Yo soy así solamente.

Algunas ventajas de Linq, las leo aquí como fáciles de probar, fáciles de depurar, etc., pero no están conectadas con la salida final o el usuario final.Esto siempre causará problemas de rendimiento al usuario final.¿Cuál es el punto de cargar muchas cosas en la memoria y luego aplicar filtros al usar LINQ?

Nuevamente, TypeSafety advierte que "tenemos cuidado de evitar encasillamientos incorrectos", lo cual nuevamente es de mala calidad y estamos tratando de mejorar mediante el uso de linq.Incluso en ese caso, si algo cambia en la base de datos, p.tamaño de la columna String, entonces linq debe volver a compilarse y no sería seguro sin eso.Lo intenté.

Aunque encontramos que es bueno, agradable, interesante, etc. mientras trabajamos con LINQ, tiene la gran desventaja de hacer que el desarrollador sea perezoso :) y se ha demostrado 1000 veces que es malo (puede ser el peor) en rendimiento en comparación con los procesos almacenados.

Deja de ser perezoso.Me estoy esforzando mucho.:)

Procesos almacenados frente a código (Discusión previa)

Para operaciones CRUD simples con un único punto de acceso a datos, yo diría que opte por LINQ si se siente cómodo con la sintaxis.Para una lógica más complicada, creo que los sprocs son más eficientes en cuanto a rendimiento si eres bueno en T-SQL y sus operaciones más avanzadas.También cuenta con la ayuda de Tuning Advisor, SQL Server Profiler, depurando sus consultas desde SSMS, etc.

El procedimiento almacenado facilita las pruebas y puede cambiar la consulta sin tocar el código de la aplicación.Además, con linq, obtener datos no significa que sean los datos correctos.Y probar la exactitud de los datos significa ejecutar la aplicación, pero con el procedimiento almacenado es fácil probarla sin tocar la aplicación.

El resultado se puede resumir como

LinqToSql para sitios pequeños y prototipos.Realmente ahorra tiempo para la creación de prototipos.

sps:Universal.Puedo ajustar mis consultas y comprobar siempre ActualExecutionPlan/EstimatedExecutionPlan.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Tanto LINQ como SQL tienen sus lugares.Ambos tienen sus desventajas y ventajas.

A veces, para la recuperación de datos complejos, es posible que necesite procesos almacenados.Y a veces es posible que desee que otras personas utilicen su proceso almacenado en Sql Server Management Studio.

Linq to Entities es excelente para un desarrollo CRUD rápido.

Seguro que puedes crear una aplicación usando solo uno u otro.O puedes mezclarlo.Todo se reduce a tus necesidades.Pero los procesos almacenados de SQL no desaparecerán pronto.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow