¿Es LINQ más eficiente que las sentencias SQL ordinarias?
Linq es un concepto con un alcance relativamente grande. Incluye no solo linq a sql, sino también el linq a xml correspondiente, etc. Por lo tanto, no hay comparación entre las declaraciones linq y SQL.
Pero si lo comparas con linq to sql, sigue siendo muy comparable a SQL. En general, ¿debe comprender a qué aspecto de la eficiencia se refiere? ¿Es la eficiencia de ejecución de la base de datos? ¿O es la eficiencia operativa general del software terminado? ¿O eficiencia en el desarrollo?
En términos de eficiencia de desarrollo, linq to sql es obviamente mucho más eficiente que SQL. Podemos implementar fácilmente la programación usando linq to sql y la cantidad de código se reduce considerablemente. Entonces, desde la perspectiva del desarrollo, la eficiencia de linq to sql es sin duda mayor que la de la conexión directa de base de datos y SQL.
Si lo considera desde la perspectiva del compilador, en general, linq to sql es una nueva tecnología introducida y su eficiencia definitivamente no es tan buena como la de SQL. Afortunadamente, esta parte de compilación no requiere la participación de desarrolladores ni de ningún usuario, por lo que incluso si es menos eficiente, no tendrá ningún impacto en el software.
Quizás te interese más la última parte. ¿Quién tiene conexiones más rápidas a la base de datos y mejor eficiencia de ejecución? La respuesta es linq to sql en lugar de declaraciones directas. Generalmente, lo que usamos declaraciones directas requiere ejecución inmediata, pero de hecho, muchas veces no necesitamos tanto. Linq to SQL en realidad muestra que algunos objetos con la misma estructura de tabla se generarán automáticamente. Estos objetos también son declaraciones compiladas directamente cuando se contacta con la base de datos. Cuando se contacta directamente, la eficiencia de los dos es la misma.
Sin embargo, si procesamos los datos, descubrirá por qué linq to sql es más eficiente. Porque al leer, no solo leerá la tabla actual para completar los objetos generados, sino que también retrasará la lectura de sus tablas relacionadas, lo que le brinda una gran conveniencia para usar tablas relacionadas. ¡Entonces la eficiencia de lectura de sus tablas relacionadas será más rápida!
Pero pase lo que pase, todos están basados en ado.net, pero algunos se generan automáticamente y no es necesario que lo hagas en absoluto. El único efecto negativo es que los datos leídos por linq a sql se convierten en el sistema. Aunque su eficiencia es peor, trae otro beneficio, es decir, el problema de inyección SQL que solemos decir ya no ocurre. .
De hecho, en la solución ADO.net, utilizamos la solución de lector de datos, que es relativamente eficiente, pero extremadamente pobre para las actualizaciones. La solución que utiliza el adaptador de datos es menos eficiente y es bastante buena para las actualizaciones de datos. Sin embargo, para linq to sql, en realidad utiliza una solución de almacenamiento en caché de datos, lo que significa que linq to sql en realidad almacena en caché los datos de la base de datos en objetos. el objeto ha cambiado y hay necesidad de retroalimentación, puede proporcionar retroalimentación, pero esta retroalimentación es controlable y transaccional. Nos ha traído beneficios en todos los aspectos.
Podemos enviar cambios después de actualizar una gran cantidad de contenido, entonces esta teoría de eficiencia optimizará su declaración original en términos de comprensión y eficiencia. Por tanto, linq to sql no supone una disminución del rendimiento, sino una mejora.
Estrictamente hablando, linq to sql no guarda código. Por el contrario, agrega una gran cantidad de código. Afortunadamente, estos códigos son generados automáticamente por el marco linq to sql. Si se hiciera manualmente, sería propenso a errores. Pero cuando lo usamos, dado que el marco ha completado la mayor parte del código, usamos linq to sql más expresiones lambad o expresiones de consulta, ¡y nuestro código se vuelve mínimo y extremadamente conciso! Y si usa expresiones lambad o expresiones de consulta, su eficiencia obviamente no es tan directa como SQL directo.
¡La eficiencia de lectura empeorará!
Esto se debe a que las expresiones lambda o las expresiones de consulta son el resultado de una compilación dinámica, no una compilación directa. Necesitan compilar y optimizar declaraciones para demostrar la eficiencia, pero en términos de rendimiento, hay demasiadas. El procesamiento en una etapa no es tan directo como el de SQL. Pero, en general, cuando se usa linq to sql con expresiones de consulta o expresiones lambad, aunque la eficiencia es ligeramente peor, aporta simplicidad y comprensibilidad del código. Si no se utilizan expresiones de consulta y expresiones lambad, linq Las ventajas y desventajas de to. sql aún no se han reflejado. Por lo tanto, no es la eficiencia de linq to sql lo que es deficiente, sino el hecho de que utilizamos la compilación dinámica de expresiones de consulta lo que resulta en una eficiencia deficiente. En lo que respecta a linq to sql, ¡la eficiencia no es mala!