LINQ to SQL vs procedimientos almacenados? [cerrado]

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: usar cualquier couples lo empareja estrechamente con su modelo de datos. Un DBA no tiene libertad para realizar cambios en el modelo de datos sin obligarle a cambiar su código compilado. Con los procedimientos almacenados, usted puede ocultar este tipo de cambios en cierta medida, ya que la lista de parámetros y el conjunto de resultados devueltos por un procedimiento representan su contrato, y las entrañas se pueden cambiar, siempre y cuando ese contrato todavía se cumpla.

Y también, 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 está ejecutando lento, el DBA puede centrarse totalmente en el código de forma aislada, y tiene muchas opciones, solo para que el contrato esté todavía satisfecho cuando haya terminado.

He visto muchos, muchos casos en los que los 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 implementado y compilado.

Tal vez un enfoque hybird sería bueno con Linq? Linq puede, por supuesto, usarse para llamar a procedimientos almacenados.

Linq a Sql.

Sql server almacenará en caché los planes de consulta, por lo que no hay ganancia de rendimiento para sprocs.

Sus sentencias linq, por otro lado, serán lógicamente parte de 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 ahora mismo solo usaría Linq, sin sprocs.

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

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

1. Depurar mi DAL nunca ha sido tan fácil.
2. La seguridad del 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 sobre cualquier cosa que implemente la interfaz IQueryable, podrá utilice la misma sintaxis para consultar XML, Objetos y cualquier otra fuente de datos sin tener que aprender una nueva sintaxis

LINQ hinchará la caché del procedimiento

Si una aplicación está usando LINQ para SQL y las consultas implican el uso de cadenas que pueden ser muy variables en longitud, la caché del procedimiento 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 contra la Persona.Tabla 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 enlazada con un NVARCHAR(7), y la otra con un NVARCHAR(11). Ahora imagina 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 la misma consulta.

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

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

Especialmente si se usa 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 comprobación de sintaxis completa, comprobación de estilo, comprobación de referencias y restricciones y más. También proporciona capacidades completas de pruebas unitarias y herramientas de refactorización.

LINQ hace realidad prueba unitaria imposible ya que (en mi mente) falla la prueba ÁCIDA.

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

Compilado en una sola 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 tiene que aprender TSQL con LINQ: No, no lo sabes, 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 solo porque los cambios cumplan con 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, aplicaciones poco acopladas son el objetivo final de todos los buenos programadores, ya que realmente aumentan la flexibilidad. Ser capaz de cambiar las cosas en el aislamiento es fantástico, y son sus pruebas unitarias las que asegurarán que todavía está devolviendo resultados apropiados.

Antes de que todos se molesten, creo que LINQ tiene su lugar y tiene un gran futuro. Pero para aplicaciones complejas y de uso intensivo de datos, no creo que esté listo para reemplazar los procedimientos almacenados. Este fue un punto de vista al que me había hecho eco un MVP en TechEd este año (permanecerán sin nombre).

EDITAR: El lado del Procedimiento Almacenado de LINQ a SQL es algo que todavía necesito leer más sobre-dependiendo de lo que encuentre puedo alterar mi diatriba anterior;)

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

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

(1)La gente dice que el estado LINQ puede "almacenar en caché" en SQL server, por lo que no pierde rendimiento. Parcialmente cierto. "LINQ to SQL" en realidad es el tiempo de ejecución que traduce la sintaxis LINQ al estado TSQL. Así que desde la perspectiva del rendimiento, un código duro ADO.NET La sentencia SQL no tiene diferencia than LINQ.

(2)Dado un ejemplo, una interfaz de usuario de servicio al cliente tiene una función de "transferencia de cuenta". esta función puede actualizar tablas de 10 DB y devolver algunos mensajes de una sola vez. Con LINQ, debe construir un conjunto de instrucciones y enviarlas como un lote a SQL Server. el rendimiento de este lote LINQ->TSQL traducido difícilmente puede coincidir con el procedimiento almacenado. ¿Razón? porque puede modificar la unidad más pequeña de la instrucción en el procedue almacenado mediante el generador de perfiles SQL integrado y la ejecución herramienta de plan, no se puede hacer esto en LINQ.

El punto es, cuando se habla de una sola tabla 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 el rendimiento.

(3)"LINQ to SQL" fácilmente hace que los novatos introduzcan cerdos de rendimiento. Cualquier tipo 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 tan fácil para un novato para escribir tal 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ó,. NET runtime simplemente traduce esto a un lote de actualización. Si solo hay 500 líneas, esto es un lote TSQL de 500 líneas; Si hay millones de líneas, esto es un éxito. Por supuesto, el usuario experimentado no utilizará esta manera para hacer este trabajo, pero el punto es, es tan fácil caer de esta manera.

El mejor código es no code, y con 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 más allá de cualquier otra consulta LINQ aparte de instanciar un objeto context.

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 la seguridad de forma centralizada 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? Views and Los procedimientos almacenados me dan eso. Si LINQ puede hacer todo eso, y hacer que nuestros programadores sean más productivos, lo agradeceré welcome ¿alguien tiene experiencia usándolo en este tipo de entorno?

Un DBA no tiene libertad para hacer cambios al modelo de datos sin forzarlo para cambiar su código compilado. Con procedimientos almacenados, puede ocultar estos cambios hasta cierto punto, ya que la lista de parámetros y el conjunto de resultados) devuelto de un procedimiento representar su contrato, y las entrañas pueden ser cambiado, siempre y cuando el contrato aún se cumple.

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 con 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 de Fortune 500 durante muchos años, en muchos niveles, incluida la administración, y francamente, nunca contratarí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 en silos, 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 los datos gestión.

Pero las grandes empresas se mueven dolorosamente lentamente en la arena del desarrollo, y esto es extremadamente costoso. Hay momentos en los que necesitas moverte más rápido para ahorrar tiempo y dinero, y LINQ proporciona eso y más con creces.

A veces pienso que los DBA están sesgados en contra de 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 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 mucho más rápido que un ciclo de edición de compilación en cualquier entorno de Visual Studio. Usted acaba de editar, F5 y pulse seleccionar y está fuera de la carrera.

D) Es más fácil administrar e implementar procedimientos almacenados que ensamblajes.. usted acaba de poner el archivo en el servidor, y pulse F5...

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

Honestamente, creo que lo último sería que MS aumentara t-sql para que pueda hacer una proyección de unión implicadamente de la manera en que lo hace linq. t-sql debería saber si quería hacer un pedido.lineitems.parte, por ejemplo.

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

También existe el problema de una posible reversión 2.0. Créeme, me ha pasado un par de veces, así que estoy seguro de que le ha pasado a otros.

También estoy de acuerdo en que la abstracción es lo mejor. Junto con el hecho de que el propósito original de cualquier OR es hacer que los RDBMS coincidan muy bien con los conceptos de OO. Sin embargo, si todo funcionaba bien antes de LINQ al tener que desviarse un poco de los conceptos de OO, entonces al diablo. Los conceptos y la realidad no siempre encajan bien. No hay lugar para fanáticos militantes en ELLA.

Asumo que te refieres a Linq Para 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. Prueba a crear perfiles para un objeto de campo de 5 (tipos simples) con más de 100.000 consultas select para averiguar si hay una diferencia real.

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

Según los gurús, defino LINQ como motocicleta y SP como automóvil. Si desea hacer un viaje corto y solo tiene pasajeros pequeños(en este caso 2), vaya con gracia con LINQ. Pero si quieres ir de 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 (negocios), duración (tiempo) y pasajeros (datos).

Espero que ayude, puede que me equivoque. : D

Todas estas respuestas que se inclinan hacia LINQ se refieren principalmente a la FACILIDAD de DESARROLLO que está más o menos conectada con la mala calidad de la codificación o la pereza en la codificación. Sólo soy así.

Algunas ventajas o Linq, leo aquí como , fácil de probar, fácil de depurar, etc, pero estos no están conectados a la salida final o al usuario final. Esto siempre va a causar el problema al usuario final en el rendimiento. ¿Cuál es el punto de carga de muchas cosas en la memoria y luego la aplicación de filtros en el uso de ¿LINQ?

De nuevo TypeSafety, es la precaución de que "tenemos cuidado de evitar el encasillamiento incorrecto" que de nuevo la mala calidad que estamos tratando de mejorar mediante el uso de linq. Incluso en ese caso, si algo en la base de datos cambia, por ejemplo, el tamaño de la columna de cadena, entonces linq necesita ser recompilado y no sería typesafe sin eso .. Lo intenté.

Aunque encontramos que es bueno, dulce, interesante, etc. mientras trabajamos 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 Procs almacenados.

Deja de ser perezoso. Me estoy esforzando. :)

Procs vs Código almacenado (Discusión anterior)

Para operaciones CRUD simples con un solo punto de acceso a datos, diría que vaya 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 tiene la ayuda de Tuning Advisor, SQL Server Profiler, depurar sus 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 corrección de los datos significa ejecutar la aplicación, pero con el procedimiento almacenado es fácil de 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 afinar mis consultas y siempre comprobar 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 procs almacenados. Y, a veces, es posible que desee que otras personas usen su proc almacenado en Sql Server Management Studio.

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

Seguro que puedes crear una aplicación usando solo una u otra. O puedes mezclarlo. Todo se reduce a sus necesidades. Pero los procs almacenados SQL no desaparecerán muy pronto.