visual studio online framework consultas sql linq-to-sql linq-to-entities

studio - linq to sql vs entity framework



¿Linq to SQL no pierde el punto? ¿No son ORM-mappers(SubSonic, etc.) soluciones subóptimas? (24)

Me gustaría que la comunidad tome algunas reflexiones sobre Linq para Sql y otros mapeadores de ORM.

Me gusta Linq a Sql y la idea de expresar la lógica de acceso a datos (o las operaciones CRUD en general) en su lengua de desarrollo nativa en lugar de tener que lidiar con el "desajuste de impedancia" entre C # y SQL. Por ejemplo, para devolver una lista de instancias de eventos compatible con ObjectDataSource para una capa empresarial, utilizamos:

return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })

Si tuviera que implementar esto usando antiguas construcciones SQL-to-C #, tendría que crear una clase Command, agregar el parámetro EventID (usando una cadena para describir el argumento "@EventID"), agregar la cadena de consulta SQL al Clase de comando, ejecute el comando y luego use (cast-type) nwReader ["FieldName"] para extraer cada valor de campo devuelto y asígnelo a un miembro de una instancia recién creada de mi clase EventData (yuck).

Entonces, esa es la razón por la cual personas como Linq / SubSonic / etc. y estoy de acuerdo.

Sin embargo, en una visión más amplia, veo una serie de cosas que están mal. Mi sensación es que Microsoft también ve algo mal y es por eso que están matando a Linq a SQL y tratando de mover personas a Linq a Entidades. Solo que creo que Microsoft se está duplicando en una mala apuesta.

Entonces, ¿qué está mal?

El problema es que hay astronautas de arquitectura , especialmente en Microsoft, que miran Linq a Sql y se dan cuenta de que no es una verdadera herramienta de gestión de datos: todavía hay muchas cosas que no se pueden hacer fácilmente en C # y apuntan a solucionarlo . Ves esto manifestado en las ambiciones detrás de Linq to Entities, publicaciones de blog sobre la naturaleza revolutionary de Linq e incluso el desafío LinqPad .

Y el problema con eso es que asume que SQL es el problema. Es decir, para reducir una incomodidad leve (desajuste de impedancia entre SQL y C #), Microsoft ha propuesto el equivalente de un traje espacial (aislamiento total) cuando una curita (Linq a SQL o algo similar) funcionaría bien.

Por lo que puedo ver, los desarrolladores son lo suficientemente inteligentes como para dominar el modelo relacional y luego aplicarlo de forma inteligente en sus esfuerzos de desarrollo. De hecho, iría más allá y diría que Linq para SQL, SubSonic, etc. ya son demasiado complejos: la curva de aprendizaje no es muy diferente de dominar SQL. Dado que, en el futuro previsible, los desarrolladores deben dominar SQL y el modelo relacional, ahora nos enfrentamos al aprendizaje de dos lenguajes de consulta / CRUD. Peor aún, Linq es a menudo difícil de probar (no tiene una ventana de consulta), nos quita una capa del trabajo real que estamos haciendo (genera SQL) y tiene un soporte muy torpe (en el mejor de los casos) para construcciones de SQL como Manejo de fechas (por ejemplo, DateDiff), "Tener" e incluso "Agrupar por".

¿Cuál es la alternativa? Personalmente, no necesito un modelo diferente para el acceso a datos como Linq a Entidades. Prefiero simplemente abrir una ventana en Visual Studio, ingresar y validar mi SQL, y luego presionar un botón para generar o complementar una clase C # para encapsular la llamada. Como ya sabes SQL, ¿no prefieres simplemente ingresar algo como esto?

Select EventID, Title From Events Where Location=@Location

y terminan con una clase EventData que A) contiene los campos EventID y Title como propiedades y B) tiene un método de fábrica que toma una cadena ''Location'' como argumento y que genera una List <EventData>? Tendría que pensar cuidadosamente sobre el modelo de objetos (obviamente, el ejemplo anterior no se ocupa de eso), pero el enfoque fundamental de seguir usando SQL mientras se elimina la falta de coincidencia de impedancia me atrae muchísimo.

La pregunta es: ¿estoy equivocado? ¿Debería Microsoft reescribir la infraestructura SQL para que ya no tenga que aprender SQL / administración de datos relacionales? ¿Pueden reescribir la infraestructura SQL de esta manera? ¿O crees que una capa muy delgada sobre SQL para eliminar el dolor de configurar parámetros y acceder a campos de datos es suficiente?

Actualización Quería promocionar dos enlaces hacia arriba porque creo que capturan aspectos importantes de lo que estoy buscando. Primero, CodeMonkey señala un artículo titulado "El Vietnam de la informática". Lleva un tiempo comenzar, pero es una lectura muy interesante. En segundo lugar, AnSGri apunta a una de las piezas más prominentes de Joel Spolsky: La Ley de las Extracciones Leaky . No es exactamente sobre el tema, pero está cerca y es una gran lectura.

Actualización 2: He dado la "respuesta" a ocdecio aunque hay muchas respuestas excelentes aquí y la elección de la respuesta "correcta" es puramente subjetiva. En este caso, su respuesta cuadraba con lo que creo que es realmente la mejor práctica dado el estado actual de la tecnología. Sin embargo, este es un área que espero evolucionar, por lo que las cosas pueden cambiar. Me gustaría agradecer a todos los que contribuyeron, he votado a favor de todos los que creo que dieron una respuesta reflexiva.

Como señaló Dmitriy, los desarrolladores no conocen SQL. Más precisamente, la mayoría conoce SQL, pero no lo entiende y definitivamente no le gusta, por lo que tienden a buscar la bala mágica, creando la demanda de cosas como Linq para hacer la ilusión (hm, abstracción) que usan. usar algo diferente a sus clases queridas.

Eso es muy malo, ya que la ley de las abstracciones con fugas siempre es cierta.

Algunas soluciones ORM son definitivamente buenas (por ejemplo, JPA / Hibernate), no porque al usarlas no tenga que preocuparse por SQL. De hecho, para usar JPA de manera efectiva, se necesita una comprensión muy profunda de la DB en general, en particular las habilidades de consulta. Lo bueno es que hacen que la máquina haga el trabajo aburrido , hasta el punto en que genera automáticamente toda la base de datos desde cero.

Linq to SQL, como creo, no resuelve un problema real. Es una especie de otra presentación, nada más. Puede ser bueno, aunque complica demasiado el lenguaje ya complejo. Por otro lado, Linq to Objects es un concepto muy interesante, porque es una especie de SQL que consulta las colecciones.

Creo que la lógica detrás de estas cosas es que la sobrecarga de construir y ejecutar una declaración SQL en la capa de infraestructura es insignificante en comparación con la sobrecarga en otras partes del sistema (por ejemplo, un viaje de solicitud HTTP es de órdenes de magnitud más largos).

Las ventajas: el desarrollo rápido, las consultas que se ajustan al idioma en lugar de ser cadenas escapadas, etc., a menudo superan las desventajas. Si el rendimiento es un problema, entonces puede optimizarlo más adelante.

No creo que "no necesite saber SQL" sea un factor. Cualquier desarrollador decente tendrá que saber SQL en algún momento de su desarrollo. La idea de una capa de abstracción de base de datos es eliminar el esfuerzo de generar código repetitivo para consultas de bases de datos.

De hecho, en nuestro sistema en Java, creé una utilidad de generador de códigos que tomaba clases anotadas y generaba una API CRUD completa, y manejaba todas esas cosas estrafalarias que recogía con el tiempo. Es mucho más fácil crear su modelo y anotarlo que escribir un DAO. Escale esa herramienta y termine con LINQ o Hibernate o una miríada de otras soluciones ORM DB.

Creo que la popularidad de los ORM ha sido generada por los desarrolladores que desarrollan capas de datos y escriben el mismo código de CRUD una y otra vez aplicación tras aplicación. Los ORM son solo otra herramienta / tecnología que les permite a los desarrolladores dedicar menos tiempo a escribir las mismas declaraciones SQL una y otra vez y concentrarse en la lógica de la aplicación (con suerte).

Debe dejar de preocuparse y aprender a amar el ORM. Abstracciones como estas nos ayudarán a enfocar nuestras habilidades y avanzar en el campo.

Todavía hay mucho espacio para aprovechar las habilidades funcionales que ha adquirido y aplicarlas en la capa de aplicación. De hecho, este es uno de los puntos fuertes de LINQ to SQL sobre otros ORM.

Solo puedo estar de acuerdo con muchos de los otros comentarios. El tiempo que ahorra, puede centrarse en refinar su modelo de dominio y hacer una mejor aplicación. Y, una vez que haya identificado el cuello de botella, utilícelo para crear SQL optimizado.

Lo que podría no ser inmediatamente obvio es que el ORM viene con una serie de características que son realmente agradables. El mapa de identidad que ayuda a evitar cargar elementos una y otra vez, la carga diferida lo ayuda a expresar el dominio con menos plomería y la unidad de trabajo lo ayuda a realizar un seguimiento de los cambios y optimizar las escrituras de la base de datos.

Durante al menos 6 años he estado usando mi propio ORM que se basa en un concepto muy simple: proyección. Cada tabla se proyecta en una clase, y SQL se genera sobre la marcha en función de la definición de la clase. Todavía me exige saber SQL, pero se ocupa del 90% de CRUD simple, y nunca tuve que administrar conexiones, etc., y funciona para los principales proveedores de DB.

Estoy contento con lo que tengo y no encontré nada por lo que valga la pena descartarlo.

El diseño de Linq y el marco de linq to entities ciertamente tienen usos como herramienta de orm, pero la gran idea es que se utilizará como una API común para consultar CUALQUIER fuente de datos, no solo RDBMS.

Recuerdo haber leído que linq, aunque obviamente diseñado con SQL en mente, pretende ser un lenguaje de consulta para cualquier almacén de datos. Puede escribir consultas de linq para SQL, pero también puede escribir teóricamente consultas de linq que se dirigen a ldap, sistemas de archivos, intercambio, servicios web, ad infinitum. No puedes usar SQL para esos programas.

También necesita aprender una API diferente para casi cada almacén de datos. Linq les da a todos un objetivo común para crear una API de acceso a datos.

Queda por ver si esta visión funciona o no, pero esa es la idea. Creo que como queremos que los sistemas interactúen más y más, podemos encontrar algunos usos muy buenos para l2e.

Agregaré algunas referencias si puedo encontrarlas de nuevo.

http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/

En mi humilde opinión, OR / M no se trata solo de ''abstraer el SQL'' u ocultar el SQL, o habilitar la compatibilidad con varios DBMS.

Le permite concentrarse más en el dominio de su problema, ya que debe dedicar menos tiempo a escribir las aburridas consultas SQL de CRUD. Por otro lado, si está utilizando un buen OR / M, este OR / M debería permitirle escribir consultas SQL si esto parece ser necesario.

Una OR / M puede ser una herramienta poderosa si la usa correctamente; puede ocuparse de la carga diferida, consultas / asociaciones polimórficas ...
No me malinterpretes; no hay nada de malo con SQL simple, pero, si tiene que cuidarse de traducir su modelo relacional (bien pensado y normalizado) a un expresivo modelo OO / dominio, entonces creo que está gastando mucho tiempo haciendo plomería.

Usar un OR / M tampoco significa que usted, como desarrollador, no debe tener conocimiento de SQL. Lo contrario es verdad.
Conocer SQL y saber cómo escribir una consulta SQL eficiente, le permitirá -imho- habilitar correctamente un OR / M.

También debo admitir que estoy escribiendo esto con NHibernate en mente. Este es el OR / M que estoy usando atm, y no he usado Linq para SQL o Linq para entidades (todavía).

Estoy de acuerdo 100%. Mucho de esto es el resultado del hecho de que las habilidades de codificación de procedimientos y las habilidades de codificación SQL son muy diferentes; y este hecho no es ampliamente reconocido. Entonces, hasta que esa realización llegue, los programadores buscan maneras de hacer que sus habilidades sean transferibles de un dominio a otro.

No funciona

Simplemente debe aprender cómo cambiar de fase: aprenda a pensar en su código de manera diferente según el dominio al que se dirige.

¿Alguien más ha notado cuánto más compleja y prolija se vuelve una consulta cuando está mapeada de SQL a LINQ? Al igual que en todos los ejemplos en línea?

Hago tanto la programación de bases de datos como la de aplicaciones distribuidas (web y compilada) y me apetece tomarse el tiempo para desarrollar capas de acceso a datos basadas en procedimientos almacenados. Personalmente, prefiero hacer modelado de datos e identificar los procesos necesarios al principio del proceso de desarrollo ... parece ayudar a descubrir problemas de lógica / estructura de diseño / interfaz.

No soy un gran admirador de la programación en línea de la base de datos (ya sea que el código sql esté generado a mano o en máquina). Creo que la base de datos de la aplicación es la base de datos y que vale la pena tomarse el tiempo para codificar manualmente los procesos almacenados.

Dicho esto, estoy intrigado por el concepto OODBMS y espero que algún día pueda trabajar en un entorno de producción.

Hubo otra pregunta aquí que preguntaba sobre los ORM en general. Échale un vistazo para saber si la desajuste de impedancias es tan importante como ese.

La afirmación de Dmitry de que a los desarrolladores no les gusta SQL puede tener mucha verdad, pero la solución no es solo ORM. La solución es contratar como parte del equipo de desarrollo un DBA de desarrollo. En mi compañía, mi equipo de desarrollo .net tiene un excelente DBA Oracle que no hace absolutamente ningún trabajo de producción de dba. Su papel en nuestro equipo es el modelado de datos, el diseño físico de bases de datos, la creación de procesos almacenados, el análisis de datos, etc. Es la razón por la que nuestro lado db es tan limpio y funcional. Todo nuestro acceso DB es a través de procs almacenados.

¿Qué es un DBA de desarrollo? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/

Permítanme prolocar esto diciendo que soy un tipo de base de datos teñido en la lana.

Como una generalización excesiva : los desarrolladores no conocen SQL. Los desarrolladores realmente no quieren saber SQL. Pueden escribirlo, pueden diseñar tablas, pero les hace sentir mal. Tienden a hacer cosas estúpidas cuando la consulta necesaria es más que una simple unión. No porque los desarrolladores sean estúpidos, porque no pueden molestarse. Les gusta vivir en un mundo donde solo tienen que lidiar con un espacio conceptual; pasar de objetos a tablas y volver es un cambio de contexto al precio que no les gusta pagar.

Esto no significa que sean malos o incorrectos; significa que hay una oportunidad de mejora. Si a sus clientes (en este caso, los desarrolladores que utilizan su marco) no les gustan el SQL y las tablas, proporcióneles una capa de abstracción que les permita escapar sin tener que lidiar con el problema subyacente.

Es la misma lógica que hace que la recolección de basura / administración automatizada de memoria sea un gran éxito. Sí, los desarrolladores pueden manejarlo; sí, pueden escribir código que está mejor optimizado sin él; pero no tener que lidiar con eso los hace más felices y productivos.

Perspectiva historica.

Cuando Codd et. Alabama. Originalmente estábamos trabajando en la teoría y la implementación de las bases de datos relacionales, un tema completamente separado fue "¿Cómo consultamos estas cosas?" Se propusieron varias estrategias y sintaxis, con varias fortalezas y debilidades. Uno de esos candidatos era SQL (en su forma más antigua, obviamente). Otro era QBE (Query By Example). Otro fue llamado "quel", creo; y hubo varios otros. SQL ciertamente no llegó a ser dominante porque fue aclamado como superior a todos los demás. Sin embargo, desafortunadamente, los otros casi han desaparecido, para nuestra pobreza (porque podrían usarse simultáneamente con los mismos datos).

Si Microsoft tiene una buena historia de que están reviviendo uno de estos otros idiomas, o han inventado una valiosa adición, entonces creo que sería aconsejable escucharlo. Pero hasta ahora todo lo que he visto es otro "Un anillo para gobernarlos a todos".

Existe una gran cantidad de pensamiento y rigor detrás de SQL, y una gran cantidad de durabilidad probada en el tiempo. Microsoft tiene una cierta historia de creer que su organización de desarrollo reconocidamente superior puede superar al resto de nosotros, incluidas nuestras memorias institucionales colectivas. No parece a menudo funcionar de esa manera. Mientras estemos vinculados a los almacenes de datos relacionales, deberíamos pensar dos veces acerca de los paradigmas de abstracción de superconjunto que nos alejen del metal puro con promesas de igual o mejor rendimiento.

Si desea que una base de datos funcione a medida que escala, debe diseñarse y normalizarse de acuerdo con las mejores prácticas del modelo relacional de base de datos.

Si permite que el Modelo de objetos y el ORM dicten su modelo de datos, terminará con un modelo de datos deficiente que no está normalizado y / o contiene artefactos del modelo de objetos.

1 mesa = 1 clase es una mala idea.

Para empezar, nunca, nunca, tiene clases que representen tablas de enlaces de muchos a muchos o muchos a uno. Estos corresponden a las colecciones secundarias en el modelo de objetos; los enlaces en sí no son objetos.

Si trata su base de datos como tablas para simplemente mantener sus objetos en filas (un enfoque común) y le da a la aplicación acceso directo a tablas, está renunciando a todos los beneficios de definir una capa de interfaz de servicios de bases de datos que la base de datos puede usar para proteger su perímetro

Los ORM tienen su lugar, pero si los usa simplemente para persistir en los objetos tal como están diseñados en su modelo de objetos, su base de datos no será una base de datos relacional, y no podrá ser utilizada como una para fines de ETL, informes, refactorización, etc.

Siendo el autor de un proyecto de ORM, debo admitir que mi respuesta a una pregunta como esta puede ser un poco parcial. Ya he desarrollado algunos de mis propios pensamientos acerca de la respuesta antes de leer la pregunta, por lo que ya estoy un poco anclado.

Diré que mi razón para desarrollar un ORM no se debió a la "falta de adecuación de la impedancia" entre SQL y la programación imperativa, sino únicamente con el propósito de convertirme en agnóstico de plataforma de base de datos. El primer problema de tener que escribir más código para administrar la persistencia es un pequeño obstáculo que se resuelve fácilmente si solo trabaja con un proveedor de bases de datos. Convertirse en un agnóstico de plataforma de base de datos es un problema mucho más desafiante e imo tiene un impacto mucho mayor en la rentabilidad de su negocio, suponiendo que, como yo, planea vender software a otras personas (y no solo lo use en casa).

Cuando comencé a trabajar en mis herramientas ORM hace varios años, el concepto no era práctico en mi lenguaje preferido, la mayoría de las personas con las que hablaba no entendían por qué estaba trabajando en ello y algunas voces respetadas en la comunidad tenían tanto como artículos escritos. en revistas comerciales que dicen que lo que ya hice no solo era imposible sino también indeseable. Se dieron algunos de los mismos motivos: es demasiado complejo, es limitante y agrega sobrecarga. Hoy en día, la misma comunidad tiene al menos tres herramientas populares de abstracción de bases de datos (aunque hay cierto debate sobre la definición del término ORM). La razón por la que menciono esto es porque cuando comencé a trabajar en estas herramientas, las objeciones originales tenían mucho más peso que ahora. La tecnología subyacente tanto del hardware como del software ha cambiado en los años intermedios para hacer que estas herramientas sean mucho más prácticas a largo plazo. Mi tendencia es tratar de tener una visión a largo plazo del software y trabajar en soluciones que tal vez no sean del todo prácticas, pero que serán prácticas pronto. Entonces, dado que no contaría LINQ to Entities como una buena solución para ciertos problemas.

También tiendo a preferir más opciones en lugar de menos. Por lo tanto, aunque puedo apoyar la idea de desarrollar LINQ to Entities, estoy menos dispuesto a apoyar la eliminación de LINQ to SQL simplemente porque LINQ to Entities está disponible. Los objetos son geniales para hacer lo que hacen los objetos, no hay dudas al respecto ... En mi opinión (nuevamente sesgada), surge un problema en el hecho de que las personas ven cualquier herramienta o paradigma de software dado como una "bala mágica" y quieren insistir en que todo debe ser de esa manera. Es bien sabido que una base de datos relacional es muy buena para manejar ciertas otras tareas, y el informe es un buen ejemplo. Entonces, en mi opinión, es como dispararse en el pie para insistir en que todo debe ser entidades, porque entonces te estás forzando a ti mismo a usar una herramienta ineficiente para el trabajo. Por lo tanto, con respecto a los informes en particular, deshacerme de LINQ to SQL y usar solo LINQ para entidades al menos en la superficie me suena como el patrón anti inversión de abstracción .

Así que supongo que la sinopsis de mi respuesta es la siguiente: usa un martillo si tu problema es un clavo: usa un destornillador si tu problema es un tornillo.

Codemonkey makes a very good point: stored procedures offer a level of abstraction that fulfills some of the promise of the more complex ORM models. This isn''t intuitive at first glance but I can think of an example right from my own code. I have a "check-in" sproc that touches nearly a dozen tables (who does this ID belong to? do they have a membership? Are there any messages? Do they get points for this check-in? etc.).

Modeling this in C# - no matter how sophisticated the data model - would never be a good idea as it would necessitate many trips "over the wire" to check on data and update various tables. While it is true that you can handle sprocs in Linq or other ORMS, all I need is a wrapper class that allows me to call the sproc with standard C# parameters. In fact, this was such a pressing need for me that I wrote a code generator in T-SQL to create such wrappers.

I don''t like any of the current solutions - but i prefer more choices over less choices ;-)

i used an OODBMS in a project long ago that was the closest to getting it right (unfortunatley the product had some heinous bugs and terrible tech support) - object persistence was largely invisible , handled behind the scenes (via preprocessor code-generator) and controlled by very simple Update, Delete, and Find methods and simple containers.

I''d love to see this (and perhaps some object-entity model does this well already) again, with OCL (Object Constraint Language) as the native multi-object query language

I have to agree that the outburst of ORM tools largely stems from the annoyance of writing SQL, dealing with whatever DB driver you have to use, internally abstracting between DBs (Oracle vs SQL Server, vs whatever for code reusability), and transforming data types.

Ideal solution? definately not! However, I think this is an iteration in the process of better merging the application with the data store. After all, in most cases, having a DB without an accessing application written in whatever language is practically useless. (would you really ever just install oracle, and expect all employees to work in SQLPlus directly?)

As such, I think the data store and the application are just moving together in a way that the application developer can more easilly interact with the data store.

For .NET in particular, what I''d much rather see instead of Linq is a built in way to map a class definition to an underlying data source to an underlying data store, and have all the plumbing just work.

In other words I could just say "Employee.Name = ''rally25rs'';" and the object''s property would change, and underneath that it would persist to the data store itself. Just ditch SQL completely instead of going 1/2 way like Linq to SQL does now.

Of course, a solution like that brings up issues with performance, transaction handling, etc.

Maybe the entire concept of programming language and relational database need to be rethought and realigned? At their core, they are completely separate and disjointed entities. Maybe its time to just ditch the "relational sql aware database" and build the next thing, whee executing a line of code would directly operate on the database.

I just discovered this question. I guess it''s pretty much played out by now, but I''m going to throw in my two cents anyway...

I only want to write code for the things that aren''t obvious.

CRUD code is obvious. I don''t want to write it. Therefore, ORMs are a good idea.

This doesn''t mean that ORMs don''t have problems, but the problems are with execution, not intent. As ORMs mature, the problems will diminish, and the productivity gains already available for simple scenarios will eventually extend to complex scenarios as well.

LINQ is also a good idea. Others have mentioned a number of the advantages, but all I have to do is think about the first time I tried to do a pivot in LINQ where I didn''t know the number of columns in advance. Or the first time I realized I didn''t have to create a new DataView every time I wanted to sort or filter something. LINQ empowers me to do everything I want to do with data in C#, rather than having to figure out how divide up the work between SQL and C#.

So, yes, ORMs, LINQ, and other emerging technologies are suboptimal solutions, but they don''t miss the point, and they won''t be suboptimal forever.

I think the real solution that they needed was something more like SQL literal. VB.Net 9.0 supports XML Literals , which allow you to write XML right in your code, and ensure that it''s validated and meets the DTD. A similarly nice feature would be SQL literals that allow you to write inline SQL code in your .Net code, and have it validated by the IDE. There would need to be some sort of plugin architecture to verifying the information against the database, but that could be easily written for the popular database engines. This would provide what I think to be the real solution, to the problem they were trying to solve, without resorting to sub-optimal solutions.

I wanted to write this as a reply to @SquareCog reply here , but it told me I had -1836 characters left. SO noob here so apologies if I''ve done this wrong.

In the 18th century gentleman of leisure used to study science. At that time science in its entirety was not such a large subject that a reasonably intelligent person couldn''t understand it all. By which I mean a single learned fellow could understand the entirety of scientific thinking of the time.

As time has gone by hundreds of new fields of science have been discovered and each one researched to the point where these days very few people can even understand the entirety of a single complete field of science.

So it is with programming.

These days the programming language field is large enough and growing fast enough that it is as much as can be reasonably be expected of a developer to know the entirety of his own specialised languages(s). For a skilled coder to also be expected to understand the entirety of the database field too, including database design, the nuances of native SQL and how it operates on different databases and the administration of those databases too, is possibly asking a bit much.

I think some of the responders here are glossing over some of the complexities of developing a large performant enterprise level database, knowing a ''handful of SQL statements'' most certainly does not cut it. Which is why most large software houses have dedicated teams of database developers. As Stroustrup says, ''Divide and conquer'' is the only way to effectively deal with the complexity inherent in developing and managing large software projects.

A los desarrolladores no les desagrada trabajar con SQL porque son flojos o porque les hace sentir ''asquerosos''. No les gusta trabajar con SQL porque son inteligentes. Saben mejor que nadie que solo alguien que se especialice en SQL entregará la funcionalidad de base de datos de la más alta calidad y que para que se los coloque en la posición de convertirse en desarrolladores "de todos los oficios" es una estrategia de desarrollo subóptima.

Most people have missed an essential point: in most cases, you are significantly more productive when querying in LINQ than in SQL. I''ve written an article on why this is so.

When I set the LINQPad Challenge, I wasn''t joking: I do nearly all of my ad-hoc querying in LINQ because most queries can be written more quickly and reliably in LINQ than in SQL. I''ve also designed and worked on large business applications using LINQ to SQL and seen a major gains in productivity. This is not "architecture astronaut" stuff - LINQ to SQL is a productive and practical technology that drives this very site .

The biggest hindrance with LINQ is failing to properly learn it. I''ve seen so many LINQ queries that are horrible transliterations of SQL queries to back this up. If you write LINQ queries using only your knowledge of SQL, the end result can only be the same - or worse - than SQL.

there´s no problem with linq, but with those who use it and ignore what happens "behind the scenes"

I still prefer to get my hands dirty with SQL. At least i´ll know exatcly whats happening.