¿LINQ To SQL proporcionar tiempos de respuesta más rápidos que el uso de ado.net y oledb?

Question

LINQ simplifica la programación de base de datos, sin duda, pero tiene un inconveniente?En línea de SQL requiere uno para comunicarse con la base de datos de manera que se abre la base de datos de las inyecciones.En línea de SQL también deben ser sintaxis comprobada, tiene un plan construido, y luego ejecutado, que toma preciosa ciclos.Los procedimientos almacenados también han sido un sólido estándar en una gran base de datos de programación de la aplicación.Muchos programadores que conozco el uso de una capa de datos que simplifica el desarrollo, sin embargo, no hasta el punto de LINQ hace.Es el momento de dar el SP y vaya LINQ?

Answer 1

LINQ to SQL en realidad presenta algunos de los alarmantes problemas de rendimiento en la base de datos.Básicamente, se crea múltiples planes de ejecución, basado en la longitud del parámetro que se está utilizando.He publicado acerca de un tiempo en mi blog LINQ to SQL puede causar problemas de rendimiento.

Ahora, es que decir que LINQ no tiene un lugar?Apenas.LINQ definitivamente tiene un lugar en el kit de herramientas de desarrollo, como procedimientos almacenados.En última instancia, usted desea utilizar procedimientos almacenados cuando el rendimiento es absolutamente necesario y el uso de una herramienta ORM en cualquier otra situación.

Tan lejos como en línea de SQL va, hay maneras de ejecutar en línea de SQL para que el plan está construido sólo una vez y nunca más se vuelve a compilar.La mayoría de los Orm se debe tener el cuidado de este aspecto de ajustar el rendimiento y el uso de estos métodos es generalmente la manera más segura para la ejecución de SQL, ya que te obliga a usar consultas parametrizadas.

Como la mayoría de las soluciones de base de datos, la respuesta correcta depende del problema que estamos tratando de resolver.Si usted a favor de acelerar el desarrollo de la base de datos/rendimiento de la aplicación, a continuación, utilizando LINQ o de otro DAL/herramienta ORM es el mejor camino a seguir.Si usted a favor de rendimiento a través de la facilidad de desarrollo, entonces el uso de procedimientos almacenados y puro de los conjuntos de datos va a ser su mejor apuesta.LLBLGen incluso proporciona una LINQ to LLBLGen capa así que usted puede utilizar LINQ para consultar LLBLGen de los objetos y tiene LLBLGen manejar efectivamente la construcción de sus consultas y de evitar algunos de los problemas de LINQ.

Answer 2

Su premisa básica es deficiente..

En línea de SQL requiere uno para comunicarse con la base de datos de manera que se abre la base de datos de las inyecciones.

No.Codificar el usuario ingresado los valores en una instrucción SQL que hace, pero que se podía hacer eso con los procedimientos de almacenamiento así.

La parametrización de las consultas de los guardias contra los ataques de inyección, pero en línea de SQL se puede parametrizar tan fácilmente como procedimientos almacenados.

En línea de SQL también deben ser sintaxis comprobada, tiene un plan construido, y luego ejecutado.

Todos Sql (SPs y en línea) debe ser sintaxis comprobada y tener un plan construido en su primera convocatoria.A partir de entonces, el texto exacto de la solicitud y el plan de ejecución se almacenan en caché.Si otra solicitud con el mismo texto (sin contar los parámetros), es recibida, el plan de ejecución de caché se utiliza.

Por lo tanto, si usted duro de los valores de código en línea en SQL, el texto no coinciden, y que tendrá que volver a analizar la consulta.Sin embargo, si el uso de los parámetros, el texto de la consulta partido, y obtendrá un acierto de caché.En cuyo caso, no importa si la consulta en línea de SQL o un SP.

En otras palabras, el único problema con en línea de SQL es que es fácil hacer algo que lento & inseguro.Pero la fabricación en línea de SQL rápido y seguro hay más trabajo que el uso de un SP.

Lo que nos lleva a LINQ, que siempre mediante el uso de parámetros, incluso si el disco duro de código los valores en el LINQ declaración, haciendo de "rápido y seguro" en línea de SQL trivial.

LINQ también tienen la ventaja sobre Msf de tener todo el código en un solo lugar, en vez de dispersas en dos máquinas diferentes.

Answer 3

Si usted está interesado en la evaluación comparativa, Rico Mariani tiene un excelente 5-parte del estudio que cubre la cualitativa y cuantitativa de las diferencias.

Él puede ser un MS chico, pero él es conocido como un rendimiento de nuez sus puntos de referencia son completos y bien pensado.

Answer 4

Este es un espectáculo dirigido por Maximiliano Beller.Según él, LINQ es mucho más lento.Leer su estudio global

Answer 5

Sólo pensar en el cambio de una de las columnas de nombre - ahora, cambie el (n)medidas sanitarias y fitosanitarias y (x)puntos de vista.

Hacer todo lo que es caro en la base de datos (como las búsquedas , clasificación, etc..) y no se notará un problema.

También, si desea mostrar una cuadrícula grande sin paginación ...a continuación, utilice un conjunto de datos - que es más rápido.

StackOverflow también utiliza linq2sql - ¿ve usted un problema :) ?

El uso de un ORM - es el camino a seguir en la mayoría de las aplicaciones.

PS:también, acerca de micro puntos de referencia - como ..vamos a seleccionar 10.000 filas con un ORM - NO LO hagas.No es por eso que el uso de un ORM.Si desea seleccionar 10.000 filas de ADO.

Answer 6

Depende de lo que estás haciendo.LINQ va a ser menos eficiente a los datos reales/set manipulación de una base de datos real.Pero te vas a ahorrar mucho en no tener que conectarse a la base de datos a través de una red.

Si su base de datos está en el mismo equipo o es formalmente 'bien conectado', usted está probablemente mejor uso de ella.

Pero si usted está volviendo un gran conjunto de resultados de una remota db que podría significar significativa de tiempo de transmisión, o si es realmente una breve consulta que no justificar la sobrecarga, LINQ probablemente sería mejor.

Answer 7

Debido a la estructura de LINQ to SQL, no hay manera posible de que puede ser más rápido que el uso de raw SQL, ya sea a su propio bien formado consultas o como un procedimiento almacenado.Lo LINQ, usted compra no es la velocidad, sino que el tipo de seguridad y la organización;en resumen la mayoría de los beneficios que Orm general de subvenciones usted.

LINQ to SQL no es acerca de la velocidad, se trata de la construcción de un mundo más sostenible el sistema de software.Se trata de todas las cosas de Software dedicado de Ingenieros y Arquitectos, de cosas como el acoplamiento flexible y capas

Eso no quiere decir que no se puede construir algo realmente tanto el código con LINQ, nadie le impide tiro en el pie, pero ... pero se hace correctamente, LINQ puede ayudar enormemente.No estoy diciendo que LINQ es una bala de plata, sin embargo.Tiene un sinfín de cuestiones que hacen que sea difícil de utilizar en muchas situaciones empresa, razón por la cual MS ofrece Entity Framework (ADO.NET 3.0).Por supuesto, incluso que no es perfecto, dado el reciente EF Voto de No Confianza.

Es LINQ to SQL o incluso EF mejor que raw SQL?Yo diría un rotundo Infiernos Sí.Hay otras soluciones que podrían funcionar mejor?Tal vez.