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

Question

LINQ simplifica la programación de bases de datos sin duda, pero ¿tiene un inconveniente? Inline SQL requiere uno para comunicarse con la base de datos de una cierta manera que abre la base de datos a las inyecciones. El SQL en línea también debe verificarse con sintaxis, tener un plan creado y luego ejecutarse, lo que requiere ciclos preciosos. Los procedimientos almacenados también han sido un estándar sólido en la gran programación de aplicaciones de bases de datos. Muchos programadores que conozco usan una capa de datos que simplifica el desarrollo, sin embargo, no en la medida en que lo hace LINQ. ¿Es hora de renunciar a los SP e ir a LINQ?

Answer 1

En realidad, LINQ to SQL presenta algunos problemas de rendimiento alarmantes en la base de datos. Básicamente, crea múltiples planes de ejecución basados ​​en la longitud del parámetro que está utilizando. Publiqué sobre esto hace un tiempo en mi blog LINQ to SQL may cause performance problems.

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

En lo que respecta al SQL en línea, existen formas de ejecutar SQL en línea para que el plan se construya una sola vez y nunca se vuelva a compilar. La mayoría de los ORM también deben ocuparse de este aspecto del ajuste del rendimiento y el uso de estos métodos suele ser la forma más segura de ejecutar SQL, ya que obliga a utilizar consultas parametrizadas.

Al igual que la mayoría de las soluciones de bases de datos, la respuesta correcta depende del problema que está tratando de resolver. Si favorece la velocidad de desarrollo sobre el rendimiento de la base de datos/aplicaciones, entonces el uso de LINQ u otra herramienta DAL/ORM es la mejor manera de hacerlo. Si favorece el rendimiento sobre la facilidad de desarrollo, entonces el uso de procedimientos almacenados y conjuntos de datos puros será su mejor opción. LLBLGen incluso proporciona una capa LINQ a LLBLGen para que pueda usar LINQ para consultar los objetos de LLBLGen y hacer que LLBLGen realmente maneje la creación de sus consultas y evitar algunas de las caídas de LINQ.

Answer 2

Este es un rendimiento dirigido por Maximilian Beller. Según él, LINQ es mucho más lento. Read his comprehensive study

Answer 3

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

Si su base de datos está en la misma máquina o está formalmente "bien conectada", probablemente sea mejor que la use.

Pero si obtiene un gran conjunto de resultados de una base de datos remota que podría significar un tiempo de transmisión significativo, o si es una consulta realmente corta que no justificará la sobrecarga, LINQ probablemente sea mejor.

Answer 4

Si está interesado en la evaluación comparativa, Rico Mariani tiene un excellent 5-part study que cubre las diferencias cualitativas y cuantitativas.

Puede ser un tipo de MS, pero es conocido como un experto en rendimiento: sus puntos de referencia son minuciosos y bien pensados.

Answer 5

Solo piense en cambiar el nombre de una columna; ahora cambie los (n) SP y (x) Vistas.

Haga todo lo que sea costoso en la base de datos (como búsquedas, clasificación, etc.) y no notará ningún problema.

Además, si desea visualizar una cuadrícula grande sin paginación ... entonces use un conjunto de datos, ese es más rápido.

StackOverflow también usa linq2sql - ¿ves un problema :)?

Utilice un ORM: es el camino a seguir en la mayoría de las aplicaciones.

PS: también, acerca de los micro-puntos de referencia - como ... seleccionemos 10.000 filas con un ORM - NO LO HAGA. No es por eso que utilizas un ORM. Si desea seleccionar 10.000 filas, use ADO.

Answer 6

Debido a la estructura de LINQ to SQL, no hay ninguna manera posible de que sea más rápido que utilizando SQL sin formato, ya sea sus propias consultas bien formadas o como un procedimiento almacenado. Lo que LINQ le compra no es velocidad, sino seguridad y organización; En resumen, la mayoría de los beneficios que los ORM generalmente le otorgan.

LINQ to SQL no se trata de velocidad, se trata de construir un sistema de software más fácil de mantener. Se trata de todo lo que le gusta a los Ingenieros y Arquitectos de Software dedicados, como el acoplamiento y la estratificación

Eso no quiere decir que no puedas construir un código realmente inmanejable con LINQ: nadie te impide dispararte en el pie pero usted - pero hecho correctamente, LINQ puede ayudar enormemente. No digo que LINQ sea una bala de plata, sin embargo. Tiene una serie de problemas que dificultan el uso en muchas situaciones empresariales, por lo que MS ofrece Entity Framework (ADO.NET 3.0).Por supuesto, incluso eso no es perfecto dado el reciente voto de EF de No Confidence.

¿Es mejor LINQ to SQL o incluso EF que SQL sin formato? Diría un resonante Hells Yeah. ¿Hay otras soluciones que podrían funcionar mejor? Tal vez.

Answer 7

Su premisa básica es defectuoso ..

Inline SQL requiere uno para comunicarse con la base de datos de una determinada manera que se abre la base de datos a las inyecciones.

No, no lo hace. Los valores hard-codeing ingresados ​​por el usuario en una declaración SQL sí lo hacen, pero también podrías hacerlo con los procedimientos de la tienda.

La parametrización de las consultas protege contra los ataques de inyección, pero SQL en línea se puede parametrizar con la misma facilidad que los procedimientos almacenados.

Inline SQL también debe ser comprobado-sintaxis, han construido un plan, y luego ejecutado.

Todos SQL (SPS y en línea) debe ser comprobado y sintaxis tener un plan construido en su primera llamada. A partir de entonces, el texto exacto de la solicitud & el plan de ejecución se almacena en caché. Si se recibe otra solicitud con el mismo texto exacto (sin contar los parámetros), se utiliza el plan de ejecución en caché.

Por lo tanto, si codifica valores en SQL en línea, el texto no coincidirá y tendrá que volver a analizar la consulta. Sin embargo, si usa parámetros, el texto de la consulta coincidirá y obtendrá un golpe de caché. En ese caso, no importaría si la consulta en SQL en línea o un SP.

En otras palabras, el único problema con SQL en línea es que es fácil hacer algo que ralentiza & inseguro. Pero hacer SQL en línea rápido & seguro no es más trabajo que el uso de un SP.

Lo que nos lleva a LINQ, que siempre usa parámetros, incluso si codifica los valores en la declaración LINQ, haciendo "rápido & seguro" SQL trivial en línea.

LINQ también tienen la ventaja sobre los SP de tener todo su código en un solo lugar, en lugar de dispersarlo en dos máquinas diferentes.