LINQ-to-SQL vs 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 tenía una pregunta de seguimiento:

Estamos a punto de desarrollar un nuevo proyecto donde casi todas las operaciones de nuestra base 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 tales 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? ¿Algún pros o contras específicos?

Gracias.

Algunas ventajas de LINQ sobre los sprocs:

1. Tipo de seguridad : creo que todos entendemos esto.
2. 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 agregar compatibilidad con subprocesos múltiples a LINQ. Los cambios de código son mínimos para agregar este soporte. Sería MUCHO más difícil hacer este código de acceso a datos que simplemente llama a sprocs.
3. Soporte de depuración : puedo usar cualquier depurador .NET para depurar las consultas. Con sprocs, no puede depurar fácilmente el SQL y esa experiencia está en gran medida vinculada al proveedor de su base de datos (MS SQL Server proporciona un analizador de consultas, pero a menudo eso no es suficiente).
4. Independiente del proveedor : LINQ funciona con muchas bases de datos y la cantidad de bases de datos compatibles solo aumentará. Las Sprocs no siempre son portables entre bases de datos, ya sea debido a la sintaxis variable o al soporte de características (si la base de datos admite sprocs).
5. 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 vincula con el n. ° 4.
6. Más fácil : no tiene que aprender T-SQL para acceder a los datos, ni tiene que aprender la API de acceso a datos (por ejemplo, ADO.NET) necesaria para llamar a los sprocs. Esto está relacionado con # 3 y # 4.

Algunas desventajas de LINQ vs sprocs:

1. Tráfico de red : los sprocs solo necesitan serializar sproc-name y datos de argumentos a través del cable mientras LINQ envía la consulta completa. Esto puede ser realmente malo si las consultas son muy complejas. Sin embargo, la abstracción de LINQ permite a Microsoft mejorar esto con el tiempo.
2. Menos flexible : los Sprocs pueden 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 del lenguaje (por ejemplo, C # vs ensamblador).
3. Recompilación : si necesita realizar cambios en la forma en que accede a los datos, debe recompilar, versionar y volver a implementar su ensamblado. Los Sprocs a veces pueden permitir que un DBA ajuste la rutina de acceso a datos sin la necesidad de volver a implementar nada.

La seguridad y la capacidad de administración son algo sobre lo que la gente también discute.

1. Seguridad : por ejemplo, puede proteger sus datos confidenciales al restringir el acceso a las tablas directamente y poner ACL en los sprocs. Con LINQ, sin embargo, aún puede restringir el acceso directo a las tablas y, en su lugar, colocar ACL en vistas de tablas actualizables para lograr un final similar (suponiendo que su base de datos admita vistas actualizables).
2. Capacidad de administración : el uso de vistas también le brinda la ventaja de proteger su aplicación sin interrupciones de los cambios de esquema (como la normalización de la tabla). Puede actualizar la vista sin requerir que cambie 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 aún escribiré un sproc pero accederé a él usando LINQ. :)

Generalmente soy un defensor de poner todo en procedimientos almacenados, por todas las razones por las que los DBA 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 el (los) conjunto (s) de resultados devueltos de un procedimiento representan su contrato, y las entrañas pueden cambiarse, siempre que ese contrato aún se cumpla .

Y también, si Linq se usa 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 lentamente, el DBA puede centrarse 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 que los problemas serios en una aplicación se abordaron mediante cambios en el esquema y el código en los procedimientos almacenados sin ningún cambio en el código compilado desplegado.

¿Quizás un enfoque hybird sería bueno con Linq? Linq puede, por supuesto, usarse para llamar a procedimientos almacenados.

Linq a Sql.

El servidor SQL almacenará en caché los planes de consulta, por lo que no hay aumento 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, solo usaría Linq, no sprocs.

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

Desde que me mudé a Linq he encontrado las siguientes ventajas:

1. La depuración de mi DAL nunca ha sido tan fácil.
2. La seguridad en el tiempo de compilación cuando cambia su esquema no tiene precio.
3. La implementación es más fácil porque todo está compilado en DLL. No más administración de scripts de implementación.
4. 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 hinchará el caché de procedimientos

Si una aplicación está utilizando 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 llenará con una versión de la consulta por cada longitud de cadena posible. Por ejemplo, considere las siguientes consultas muy simples creadas contra 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: una vinculada con un NVARCHAR (7) y la otra con un NVARCHAR (11). Ahora imagine si hubiera cientos o miles de cadenas de entrada diferentes, todas con diferentes longitudes. El caché de procedimientos se llenaría innecesariamente con todo tipo de planes diferentes para la misma consulta.

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

Creo que el argumento pro LINQ parece provenir de personas que no tienen un historial con el desarrollo de bases de datos (en general).

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

Más difícil de mantener y probar: VS proporciona verificación de sintaxis completa, verificación de estilo, verificación de referencia y restricción y más. También proporciona capacidades de prueba de unidad completa y herramientas de refactorización.

LINQ hace que la prueba de unidad verdadera sea imposible ya que (en mi opinión) falla la prueba de ACID.

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

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

No tiene que aprender TSQL con LINQ: No, no tiene, pero tiene 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 solo porque los cambios cumplan un contrato no significa que esté devolviendo los resultados correctos. Para poder determinar cuáles son los resultados correctos, necesita contexto y obtiene ese contexto del código de llamada.

Um, las aplicaciones ligeramente acopladas son el objetivo final de todos los buenos programadores, ya que realmente aumentan la flexibilidad. Ser capaz de cambiar las cosas de forma aislada es fantástico, y son las pruebas de su unidad las que garantizarán que aún arroje los resultados adecuados.

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

EDITAR: el lado de las cosas del procedimiento almacenado de LINQ to SQL es algo en lo que todavía necesito leer más, dependiendo de lo que encuentre, puedo alterar 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 de rendimiento, solo para "LINQ to SQL", por supuesto, podría estar totalmente equivocado ;-)

(1) La gente dice que el estado de 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 la declaración TSQL. Entonces, desde la perspectiva del rendimiento, una instrucción SQL ADO.NET codificada no tiene ninguna diferencia con respecto a LINQ.

(2) Dado un ejemplo, una IU de servicio al cliente tiene una función de "transferencia de cuenta". Esta función en sí podría actualizar 10 tablas de DB y devolver algunos mensajes de una sola vez. Con LINQ, debe crear un conjunto de declaraciones y enviarlas como un lote al servidor SQL. el rendimiento de este lote LINQ-> TSQL traducido difícilmente puede coincidir con el procedimiento almacenado. ¿Razón? debido a que puede ajustar la unidad más pequeña de la instrucción en el procedimiento Almacenado utilizando el analizador de SQL incorporado y la herramienta de plan de ejecución, no puede hacerlo en LINQ.

El punto es, cuando se habla de una sola tabla de DB 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 procedimiento almacenado es más modificable en rendimiento.

(3) "LINQ to SQL" hace que los novatos introduzcan fácilmente los cerdos de rendimiento. Cualquier persona senior de TSQL puede decirle cuándo no usar CURSOR (Básicamente, no debe 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 dicho código:

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

Puedes ver que este código fácil y decente es muy atractivo. Pero bajo el capó, el tiempo de ejecución de .NET solo traduce esto a 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, este es un éxito. Por supuesto, el usuario experimentado no usará esta forma para hacer este trabajo, pero el punto es que es muy fácil caer de esta manera.

El mejor código es sin código, y con los procedimientos almacenados debe escribir al menos un 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 tiene que escribir ningún código adicional. código más allá de cualquier otra consulta LINQ además de instanciar un objeto de contexto.

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

Pero en una gran empresa, donde las bases de datos centrales sirven como un centro de datos comunes para muchas aplicaciones, necesitamos abstracción. Necesitamos administrar de forma centralizada la seguridad y mostrar los historiales de acceso. Necesitamos poder hacer un análisis de impacto: si realizo un pequeño cambio en el modelo de datos para satisfacer una nueva necesidad comercial, ¿qué consultas deben cambiarse y qué aplicaciones deben volver a probarse? Las opiniones 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 en usarlo 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 (los) conjunto (s) de resultados devueltos de un procedimiento representan su contrato, y las entrañas pueden cambiarse, siempre que 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 solo porque los cambios cumplan un contrato no significa que esté devolviendo los resultados correctos. Para poder determinar cuáles son los resultados correctos, necesita contexto y obtiene ese contexto del código de llamada.

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

Pero las grandes empresas se mueven dolorosamente lentas en el campo del desarrollo, y esto es extremadamente costoso. Hay momentos en los que necesita moverse más rápido para ahorrar tiempo y dinero, y LINQ proporciona eso y mucho más.

A veces pienso que los DBA están predispuestos contra LINQ porque sienten que amenaza su seguridad laboral. Pero esa es la naturaleza de la bestia, damas y caballeros.

Creo que necesitas ir con procs para algo 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) No estoy convencido de que el modelado de objetos sea mejor que el modelado relacional de todos modos.

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 editas, F5 y presionas select y estás listo para las carreras.

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

E) Linq to sql todavía escribe código malo en momentos en que no lo espera.

Honestamente, creo que lo más importante sería que MS aumente t-sql para que pueda hacer una proyección de combinación de manera implícita como lo hace linq. t-sql debe 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-updatedproc . Personalmente, me alegro de no tener que escribir los procedimientos almacenados ... pwet-tu.

Además, existe el problema de la posible reversión 2.0. Confía en mí, me ha sucedido un par de veces, así que estoy seguro de que le ha sucedido a otros.

También estoy de acuerdo en que la abstracción es la mejor. Junto con el hecho, el propósito original de un ORM es hacer que RDBMS coincida muy bien con los conceptos de OO. Sin embargo, si todo funcionó bien antes de LINQ al tener que desviarse un poco de los conceptos de OO, entonces atorníllelos. 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 frente a cualquier tecnología. En este caso, cualquier diferencia entre los dos será insignificante. Intente crear un perfil para un objeto de campo 5 (tipos simples) con más de 100,000 consultas de selección para descubrir si hay una diferencia real.

Por otro lado, el verdadero factor decisivo será la pregunta sobre si se siente cómodo poniendo su lógica comercial 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), vaya con elegancia con LINQ. Pero si quieres hacer un viaje y tener una banda grande, creo que deberías elegir SP.

Como conclusión, elegir entre motocicleta o automóvil depende de su ruta (negocio), duración (tiempo) y pasajeros (datos).

Espero que ayude, puedo estar equivocado. :RE

Todas estas respuestas que se inclinan hacia LINQ se refieren principalmente a la 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. Solo soy así.

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

Una vez más, TypeSafety, advierte que "tenemos cuidado de evitar errores de tipografía", lo que de nuevo es la mala calidad que estamos tratando de mejorar utilizando linq. Incluso en ese caso, si algo cambia en la base de datos, por ejemplo, el tamaño de la columna String, entonces linq necesita ser compilado de nuevo y no sería seguro sin eso ... Lo intenté.

Aunque descubrimos que es bueno, dulce, interesante, etc., mientras trabaja con LINQ, tiene la desventaja de hacer que el desarrollador sea perezoso :) y se demuestra 1000 veces que es malo (puede ser peor) en el rendimiento en comparación con los Stored Procs.

Deja de ser perezoso. Estoy intentando mucho :)

Para operaciones CRUD simples con un único punto de acceso a datos, diría que vaya a 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 al 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, depuración de consultas de SSMS, etc.

El procedimiento almacenado facilita las pruebas y puede cambiar la consulta sin tocar el código de la aplicación. También 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 probar sin tocar la aplicación.

El resultado puede resumirse como

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

Sps: Universal. Puedo ajustar mis consultas y siempre verificar 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 usen su proceso almacenado en Sql Server Management Studio.

Linq to Entities es ideal para el rápido desarrollo de CRUD.

Claro que puedes construir una aplicación usando solo uno u otro. O puedes mezclarlo. Todo se reduce a sus necesidades. Pero los procedimientos almacenados de SQL no desaparecerán pronto.