¿Cuáles son los pros y los contras de usar consultas de linq (junto con un ORM como EF o linq2sql) VS. ¿Procedimientos almacenados (SQL Server 2008) para consultar y actualizar un modelo de datos? ¿Actuación? ¿Velocidad? Etc ...Consultas de LINQ frente a Procedimientos almacenados
Linq es definitivamente más legible cuando se encuentra en el código. Ver una llamada para ejecutar un sproc llamado "sp_GetSomething" no te dice nada como desarrollador, a menos que veas físicamente lo que hace el sproc. código de ver como
var query = from c in db.TableName
where c.Name == "foo"
select c;
Eso le dice exactamente qué datos se están sacando.
Los procedimientos almacenados, por otra parte, no requieren que vuelva a compilar la aplicación si decide cambiar el código. Si decide cambiar repentinamente una cláusula "where" o si cambia el Order By, es fácil cambiar un sproc. Cambiar el código Linq podría consumir más tiempo.
Estoy seguro de que hay muchas más, pero estas son dos que he notado.
debería ser == y no = en su muestra – turtlepick
La segunda parte podría considerarse una desventaja. Cambiar un sproc en un entorno de producción es silencioso y potencialmente mortal, mientras que los cambios en el código pasan por el control de versiones, la creación y las pruebas para garantizar la calidad. –
Depende de la versión de SQL que utilice. El plan de ejecución (que es la información utilizada por SQL para hacer una segunda llamada más rápido ...) en SQL 2008 funciona realmente bien también con un O/RM. No veo por qué usaría un O/RM y pasaría mucho tiempo reasignando todo al proceso almacenado personalizado. También un proceso almacenado es difícil de ser TDD y no le permite el concepto de unidad de trabajo y transacción
Me gustaría ir casi siempre con procedimientos almacenados por varias razones:
1) utilizando LINQ en el código para consultar una base de datos no es realmente siguiendo los principios de la mult-tier arquitectura ... cualquier cosa que implica acceder a objetos de bases de datos debe hacerse en el nivel de la base de datos. Las consultas LINQ son solo un contenedor para escribir SQL en su código. SQL o LINQ en el código es un no-no, aunque todos los ejemplos de MVC lo hacen.
2) Rendimiento ... ¡los procedimientos almacenados se ejecutan más rápido! Cada vez que ejecuta consultas desde el código, es propenso a problemas de escalabilidad y rendimiento.
3) Mantenimiento. Debido a que los procedimientos almacenados lo liberan de tener SQL o LINQ en su código, el mantenimiento de sus procedimientos almacenados se puede encargar por separado (separación de preocupaciones).
No estoy de acuerdo con casi todo lo que has escrito. – RPM1984
2) es verificablemente correcto 3) es una cuestión de preferencia y 2) es esencialmente cierto: la arquitectura de varios niveles dicta que cada nivel o nivel de una aplicación debe estar claramente separado. Si escribe código de base de datos en su aplicación, ha combinado 2 niveles en 1, violando así el principio ... es así de simple. – Zunandi
Varios niveles pueden satisfacerse simplemente colocando su capa de acceso a datos en un ensamblaje o proyecto por separado. Esto resuelve tus puntos 1 y 3. Y en cuanto al punto 2, me hacen creer que la diferencia de rendimiento en SQL2008 es mínima, si es que existe. –
Estoy de acuerdo con Peter Lee en este caso: en un entorno serio y de escala empresarial, probablemente el método de almacenamiento preferido sea el que prefiera.
Además de los comentarios de Peter, aquí hay unos cuantos más:
La EF o LINQ to SQL (o NHibernate, también) son ORM, lo que significa que quieren convertir una fila en su tabla de base de datos en un objeto. Dado que ese objeto normalmente debe contener todos los valores de esa tabla (o incluso de varias tablas, en el caso de EF), esos ORM suelen utilizar un enfoque SELECT * FROM ..... Esto significa que, como está seleccionando todas las columnas, por lo general no puede hacer uso de ningún índice de cobertura, y su rendimiento puede doler. Es un clásico "conveniencia vs. rendimiento" trade-off
Todos los ORM que conozco y que han trabajado básicamente necesitan acceso total a las tablas base. Este es un gran no-no para muchas empresas y sus DBA.Al usar los procedimientos almacenados sabiamente, puede arreglárselas sin tener que permitir el acceso a la tabla base de todos los usuarios, ¡una gran ventaja en términos de seguridad de acceso!
Estoy totalmente en desacuerdo con su primera afirmación: Método "SELECCIONAR * DESDE" - no existe. ¿Has intentado utilizar el Analizador de SQL Server para ver qué consulta se ejecuta realmente en el servidor? LinqToSQL o EF solo consultan lo que pides, nada más. – Andrei
@Andrei: y normalmente, cuando tiene un objeto que asigna 1: 1 a una tabla de base de datos y desea obtener un objeto, necesita obtener ** todas ** columnas, y obtiene un 'SELECT * FROM. .... 'Y ** sí **, he verificado esto en SQL Profiler. –
Bueno, supongo que es una cuestión de cómo usas tu modelo de datos LinqToSql/EF. Para crear una instancia de una clase "fila", no tiene que consultar la base de datos en absoluto. Si tiene que obtener solo un par de valores y aún tiene que usar el tipo de "fila" generado automáticamente, puede hacerlo de la siguiente manera: seleccione nuevo Cliente() { FULL_NAME = cx.FULL_NAME, OID = cx. OID } – Andrei
Hay 2 campos: para procs almacenados y contra procs almacenados.
He descubierto que es la falta de experiencia lo que hace que la gente vaya de una manera u otra. Hay diferentes tipos de tiendas donde desarrollamos.
En la práctica
Estoy en una tienda corporativa así que ...
Nosotros (como equipo desarrollador de DBA) con frecuencia tenemos que rescatar a los usuarios de ORM en equipos hermanos.
También hay cuestiones más sutiles, que:
+1. Una respuesta sensata e informada. – RichardOD
Tengo algunas en cuanto a su "tiene que rescatar desarrolladores" - Yo diría que el equipo necesita contratar mejores desarrolladores –
Los pro y los contras no son realmente ciertos. No puede escribir código Linq sólido sin entender sql. Si tiene que rescatar los temas de la hermana con ORM, entonces son juniors que no entienden cómo funciona un orm. Necesitan aprender a depurar y rastrear. Los procesos almacenados mueven la capa de datos a la base de datos. Linq alivia mucho de eso. En un entorno corporativo, los procesos almacenados rara vez se utilizan a menos que esté suscribiendo trabajos SSIS, SSRS, PP o sql. En otras palabras, tiene más sentido usar enlaces que SP en un entorno corporativo. Los procs almacenados necesitan Cal intensiva, de lo contrario, el DBA tiene un ego –
realmente una respuesta a su pregunta, pero no se olvide que aún puede utilizar EF on stored procs
Sí, he estado utilizando Linq2Sql para llamar a mis procedimientos almacenados por un tiempo. Parece que una combinación de los dos va a ser la mejor ruta. – stephen776
La verdadera respuesta es que es "caballos de carreras". Desde una perspectiva (como un desarrollador de db como @gbn), se almacenan los procesos todo el tiempo. Desde mi punto de vista como un desarrollador web integral de back-office, cuyo uso simultáneo de la aplicación nunca supera los 100, y que no es brillante escribiendo SQL eficiente, es LINQ (actualmente EF 4.1) todo el tiempo. Y código primero, si puedo salirse con la tuya. Esta es la decimoquinta pieza que he leído sobre el tema hoy (después de una discusión en una reunión de desarrollo) y cada pieza parece sugerir lo mismo: "caballos para cursos". Y a veces, en un mundo de back-office, no es solo la eficiencia de obtención de datos lo que debe tener en cuenta: es la rapidez (eficacia) con la que puede corregir errores y la facilidad (eficiencia) con la que la siguiente persona puede ver su el código está haciendo. Desde esta perspectiva, LINQ gana indiscutiblemente.
¿Puede agregar alguna información sobre la escalabilidad de EF 4.1 con> 100 usuarios concurrentes? ¿Qué problemas se encontrarían con las aplicaciones de mayor tráfico? – stephen776
¡Todo es relativo a su hardware, supongo! Puedes escribir todos los hermosos procesos almacenados en el mundo, pero si tienes 1 servidor de db con 1 GB de ram y 2 millones de usuarios, estarás en problemas ... – LiverpoolsNumber9
@gbn tiene una gran respuesta.
En sistemas enormes con cientos de millones de registros, la manipulación de datos en la capa de presentación simplemente no va a cortarlo. Las aplicaciones intensivas de datos (¡no las aplicaciones de blogs!) Necesitarán escalar antes de lo que piensas.
Los ORM ahorran mucho tiempo al desarrollar un sistema pequeño a mediano. Puede tener una aplicación preparada para producción en muy poco tiempo con un orm implementado correctamente. a nadie le gusta escribir crud.
También es importante recordar que la sintaxis de SQL ha sido constante durante más de 20 años. Si esto no es importante para ti, no has estado programando lo suficiente.
Mi preferencia es LINQ, verificando las consultas producidas en una herramienta como EF Profiler. Si alguna consulta generada es demasiado larga o crea N + 1s, normalmente puede ser reparada. Una vez en producción, mantengo mi ojo en las estadísticas y si una consulta lenta no se puede solucionar con el almacenamiento en caché, la moveré a un procedimiento almacenado.
Las principales ventajas a hacer sus consultas en LINQ son:
Cuando me he unido a un proyecto que tiene muchos procesos almacenados, a menudo hay muchos que no se usan (o probablemente no se usan), pero nadie se atreve a eliminarlos ya que nadie está seguro.
La única vez que comenzaría con los procedimientos almacenados sería si estuviera trabajando en un entorno corporativo en el que el acceso a la base de datos estuviera restringido de tal forma que tuviera que hacerlo.
Falsa dicotomía. OMI, puede obtener el punto óptimo de ambos mediante el uso de SQL sin procesar (que es una habilidad importante, que no deberíamos evitar) con herramientas que simplemente lo hacen más conveniente. Los procedimientos almacenados introducen algunos problemas de acoplamiento/implementación (tiempo, etc.) que la mayoría de la gente no necesita; Los ORM pueden ser de bajo rendimiento. La mayoría de las personas no van a cambiar RDBMS (y si lo hacen, será un proyecto importante de todos modos), así que: soy un gran admirador del texto de comando parametrizado. Y herramientas que ayudan, por ejemplo, apuesto.
Otro usuario publicó un ejemplo LINQ de filtrado por nombre; Bueno, aquí está lo mismo en pulcro:
string name = ...
var list = connection.Query<YourType>(
"select * from TableName where [email protected]",
new { name }).ToList();
totalmente parametrizado; muy optimizado; seguro; rápido; limpiar; fácil de hacer bien Trabajo hecho.
Una cosa más que añadir: Usando TSQL puede crear un paquete de de consultas para ser ejecutado como una unidadpara asegurarse de que el acceso a las filas está bloqueada hasta que termine su lista de consultas. Mientras sepa, creo que no se pudo hacer usando LINQ.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Esto es muy útil - por ejemplo - cuando no se desea una nueva inserción para ser ejecutado mientras que la ejecución de una lista de consultas.
Mucho se ha dicho en respuesta a la pregunta original. Mi respuesta se basa en aspectos comerciales y no técnicos.Aquí está mi experiencia, tal vez dará algunos consejos para algunos que están comenzando nuevos proyectos. Comenzamos con Asp.net + SQL Server y la aplicación se convirtió en una complicada usando alrededor de 800 procedimientos almacenados. Durante tres años nos liberamos del servidor SQL a través de un programa de Microsoft, por lo que nunca nos importó desde el principio. Cuando la cotización de licencia de más de 50K llega a la mesa (se basa en el número de núcleos/hilos y también necesita una licencia por separado para el servidor esclavo), corrimos a migrar a MySQL. Ojalá no estuviéramos usando procedimientos almacenados. Sin procedimientos almacenados, podríamos migrar fácilmente rápidamente, en unos pocos días. Nos llevó mucho más tiempo y grandes esfuerzos para reescribir los SP en MySQL. Si no está utilizando SP, su aplicación es más flexible/portátil y es más fácil depurar el código dentro de su aplicación.
Por lo tanto, si no es técnico, desde el punto de vista comercial, existe una fuerte demanda contra el uso de procedimientos almacenados en aplicaciones web. Si no utiliza SP, también puede distribuir su aplicación a clientes con esquema db (que incluirá solo tablas) mientras la lógica de su aplicación aún está oculta en Linq + EF o Linq SQL.
No es exactamente un duplicado (casi), pero vea mi respuesta here para ver cuándo usar SPROC o LINQ con Entity Framework. – RPM1984
Puede mejorar la velocidad de sus consultas de Linq utilizando [consultas compiladas] (http://www.davidhayden.com/blog/dave/archive/2008/02/19/HighPerformanceLINQToSQLCompiledQueriesORMappersEcommerceWebsites.aspx). – R0MANARMY
Wow Debería haberme dado cuenta de que no habría una respuesta abreviada para esto. Grandes respuestas hasta ahora. Tengo algunas ideas para hacer. Supuse que LINQ hubiera sido el claro favorito, pero supongo que no es tan simple ... – stephen776