LINQ-to-SQL vs procedimientos almacenados? [cerrado]


188

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.

Respuestas:


192

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. :)


33
"LINQ funciona con muchas bases de datos" Pero LINQTOSQL solo es compatible con SQL Server.
RussellH

77
LINQ to Entities funciona con Postgres y MySql además de MSSQL. No estoy seguro, pero pensé que había leído que había algo para Oracle.
bbqchickenrobot

devart dotConnect tiene algo de Oracle, pero tiene errores como el infierno. Además, no puedo superar el déficit de rendimiento que se presenta al tener que seleccionar datos de la base de datos para actualizarlos (Attach () también es posible, pero es bastante pobre)
Ed James

55
No he visto a nadie aquí mencionar la reutilización de código. No puede reutilizar su linq en una aplicación VB6 o asp o file maker pro. Si coloca algo en la base de datos, puede reutilizarlo EN TODAS PARTES. Podrías hacer un dll con linq, supongo, pero eso se está volviendo demasiado complicado y horrible. Agregar una función o proceso almacenado que se puede reutilizar es mucho más simple.
MikeKulls

Hablando de la reutilización de código en TSQL (1) buena suerte tratando de guardar los resultados de un procedimiento almacenado en una tabla temporal sin recurrir a SQL dinámico. (2) No hay mucho que pueda hacer para organizar todos sus procesos / funciones; el espacio de nombres se abarrota rápidamente. (3) Ha escrito una declaración de selección poderosa, pero ahora desea que el usuario pueda elegir la columna que se ordena: en TSQL puede que tenga que usar un CTE que haga un número de fila sobre cada columna que podría ordenarse; en LINQ se puede resolver con algunas ifdeclaraciones en un último momento.
sparebytes

77

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.


9
Una característica que descuidaste es la seguridad. Con Linq, debe exponer las tablas directamente a la aplicación. Con los procedimientos almacenados puede limitar el acceso a esos procesos y hacer cumplir los requisitos de su negocio.
NotMe

19
"Un DBA no tiene libertad para realizar cambios en el modelo de datos sin obligarlo a cambiar su código compilado". ¿Por qué abogarías por esto? Nadie debería tener "libertad" para hacer cambios, ese es el punto de la administración de la configuración. Los cambios deben pasar por desarrollo, prueba, etc. antes de la implementación independientemente.
Neil Barnwell

66
@Neil: Sí, pero no puede hacer cambios en el entorno de desarrollo sin obligar al desarrollador a cambiar el código.
Adam Robinson el

37
Tengo que decir que he visto mucho el argumento sobre el acoplamiento estrecho a las bases de datos, y no estoy seguro de que sea tan válido. En realidad, nunca me he encontrado con una situación (más allá de los ejemplos triviales) en la que quiero cambiar la base de datos que de todos modos no requiere un cambio en el código más arriba. Y realmente, en qué se diferencia Linq de los procesos almacenados o consultas parametrizadas de todos modos. Su capa de acceso a datos aún debe estar bien separada y abstraída, independientemente de si usa un ORM o algo más simple. Eso es lo que le da el acoplamiento suelto, no la tecnología que usa. Just my 2c
Simon P Stevens

77
He visto 199 procedimientos almacenados escritos innecesariamente por cada 1 cambio de esquema que estaba protegido de las aplicaciones a través de la firma del SP, pero de manera similar a lo que dijo Simon P Stevens, los cambios semánticos en el uso de los SP requerían cambios del 100% de la aplicación. tiempo de todos modos. Sin mencionar el hecho de que la existencia misma de los SP solo le ruega a algún futuro desarrollador o dba que filtre alguna lógica comercial en el SP. Luego un poco más y un poco más.

64

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.


8
No estoy de acuerdo con respecto a sus comentarios sobre ninguna ganancia para los sprocs. Perfilé una serie de enfoques para el acceso a SQL Server en un sistema de producción, y el uso de los procesos almacenados Prepare + tuvo uno de los mejores resultados. Incluso a través de múltiples llamadas de la misma lógica. Sin embargo, quizás tenga razón en un DB con bajo uso.
torial

Si usted es, y será, el desarrollador de consultas de bases de datos más hábil, utilice lo que le resulte más familiar. A diferencia del código de procedimiento, no puede decir "si da la respuesta correcta, envíela".
dkretz

55
@RussellH: Esto fue cierto para .Net 3.5, lo arreglaron en .Net 4 (tanto para L2S como para L2E)
BlueRaja - Danny Pflughoeft

3
@Kieth ¡No es el caso! Se crean muchos más planes de ejecución de Linq que los SP. Existen beneficios con el código para depurar; pero problemas con la recompilación para el ciclo de despliegue de la compañía; inflexibilidad para probar diferentes consultas de ACCIÓN, DONDE, ORDENAR POR. Cambiar el orden de la instrucción WHERE puede hacer que se procese una consulta diferente; pretratamiento; Esto no se puede hacer fácilmente en Linq. Necesita tener la capa de datos disponible para ajustar. ¿Los SP son más difíciles de mantener y probar? Si no estás acostumbrado; ¡pero los SP son beneficiosos para el cuerpo y los VLDB, la alta disponibilidad, etc.! Linq es para pequeños proyectos, trabajo en solitario; ve a por ello.
SnapJag

44
@SnapJag: tiene razón en que las sprocs le brindan más control de grano fino, pero el hecho es que el 99% del tiempo (incluso en los sistemas empresariales grandes en los que trabajo) no necesita ninguna optimización adicional. Los Sprocs son más difíciles de mantener y probar si estás acostumbrado a ellos o no: estoy muy acostumbrado a ellos (era un DBA antes de ser desarrollador) y me aseguro de que el Sproc para cada operación CRUD para cargas de tablas diferentes sea actualizado es un dolor. La mejor práctica (en mi humilde opinión) es codificar de la manera más fácil, luego ejecutar comprobaciones de rendimiento y optimizar solo donde sea necesario.
Keith el

40

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

1
Para mí, la seguridad es la clave.
bbqchickenrobot

Sin embargo, para la implementación, si está en un equipo corporativo que tiene un ciclo de implementación y existe un error que debe eliminarse rápidamente, su implementación de DLL a través del control de calidad, etc., es probablemente más estricta que la ruta de implementación de una sola base de datos guión. Sus ventajas parecen representar mejor un escenario pequeño de equipo / proyecto.
SnapJag

3
La implementación de scripts SQL que no necesitan pasar por control de calidad, no es necesariamente algo bueno aquí.
liang

27

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


10
Qué argumento más tonto: solo use una variable y su problema se resolverá.
JohnOpincar

66
@John, no sería útil usar una validación en lugar de una cadena literal, ya que al final está enviando una cadena literal a la base de datos. Puede parecer una variable en su código, pero será una cadena en el T-SQL generado que se envía a la base de datos.
kay.one el

15
SQLMenace: según la página a la que se vinculó, el problema se resuelve en VS2010.
Mark Byers el

8
Este problema era válido cuando se publicó la respuesta, pero desde entonces se ha resuelto en VS2010, por lo que ya no es un problema.
Brain2000

17

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;)


44
Aprender LINQ no es gran cosa, es solo azúcar sintáctico. TSQL es un lenguaje completamente diferente. Manzanas y naranjas.
Adam Lassek

3
El beneficio de aprender LINQ es que no está vinculado a una sola tecnología: la semántica de consulta se puede usar para XML, objetos, etc., y esto se ampliará con el tiempo.
Dave R.

55
¡Convenido! Muchas personas (desarrolladores) están buscando una solución de "velocidad de comercialización" en pequeños equipos y proyectos. Pero si el desarrollo avanza al siguiente nivel de estilo corporativo con múltiples equipos, bases de datos grandes, sistemas distribuidos de gran volumen y alta disponibilidad, ¡será una historia diferente usar LINQ! No creo que deba editar su opinión en demasiado tiempo. LINQ no es para proyectos / equipos que son más grandes y tienen múltiples personas, múltiples equipos (Dev y DBA), Y tienen un cronograma de implementación estricto.
SnapJag

17

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.


2
es fácil fallar con punteros en C / C ++ / C # ¿significa que nunca se debe usar?
bbqchickenrobot

1
¿Cuántos programadores de nivel medio manejan punteros? Linq expone esta capacidad a cualquier codificador de nivel, lo que significa que el riesgo de error aumenta dramáticamente.
Jacques

1
Estás comparando novatos en LINQ con un chico senior de TSQL. No es realmente una comparación justa. Estoy de acuerdo con su código, LINQ no es eficiente para la actualización / eliminación de lotes en general. Sin embargo, yo diría que la mayor parte de los argumentos de rendimiento entre LINQ y SP, son las reclamaciones, pero no sobre la base de medida
Liang

12

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.


10

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?


2
Trajiste un buen punto; LINQ no es una alternativa en este caso.
Meta-Knight

1
Sus diversas aplicaciones deberían estar utilizando una capa de acceso a datos común (por supuesto, ese no es siempre el caso). Si es así, puede hacer un solo cambio en la biblioteca común y volver a implementar. También puede usar algo como WCF para manejar el acceso de datos por usted. Hay una buena capa de abstracción que técnicamente podría usar linq para acceder a datos detrás de escena. Supongo que todo depende de lo que hagan sus muchachos para sus requisitos con respecto al uso de SP vs Linq.
bbqchickenrobot

8

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.


7

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.


3
Sí, nosotros, los DBA, nos sentamos a esperar todo el día para que solicite un impulso de Stored Proc a la producción. ¡No tener que hacer eso nos rompería el corazón!
Sam

6

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.


5

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.


4

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.


3

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.


1
Dado que más lugares que la aplicación pueden afectar los datos: importación de datos, otras aplicaciones, consultas directas, etc., es una tontería no incluir la lógica de negocios en la base de datos. Pero si la integridad de los datos no le preocupa, continúe.
HLGEM

3
La lógica empresarial no debería entrar en la base de datos. Debe estar en un lenguaje de programación donde se pueda depurar y administrar fácilmente. Luego se puede compartir entre aplicaciones como objetos. Algunas reglas pueden estar en la base de datos pero no la lógica de negocios.
4thSpace

3

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


1
amigos han muerto en motocicletas: P
Alex

2
también murieron personas conduciendo automóviles.
liang

1
si te equivocas
Asad Ali

3

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 :)


44
¿Cargando todo en la memoria y filtrarlo? Linq puede enviar filtros como parte de la consulta a la base de datos y devuelve el conjunto de resultados filtrado.
liang

Hay bastantes personas que creen que LINQ carga todos los datos y los procesa utilizando un bucle foreach. Eso está mal. Simplemente se compila en una consulta SQL y proporciona casi el mismo rendimiento para la mayoría de las operaciones CRUD. Pero sí, no es una bala de plata. Hay casos en los que el uso de T-SQL o procesos almacenados puede resultar mejor.
Es una trampa

Estoy de acuerdo con los dos contraargumentos. Sin embargo, no es completamente cierto que linq envíe todos los filtros a DBMS para trabajar en él. Hay algunas cosas que funcionan en la memoria, una de ellas es distinta.
Manish

2

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.


2

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.


1

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.



0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.