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

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 express 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 list de instancias de events 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 class Command, agregar el parámetro EventID (usando una cadena para describir el argumento "@EventID"), agregar la cadena de consulta SQL al Clase de command, ejecute el command 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 class 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 architecture , especialmente en Microsoft, que miran Linq a Sql y se dan count 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 revolucionaria de Linq e incluso el desafío LinqPad .

Y el problema con eso es que asume que SQL es el problema. Es decir, para networkingucir 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 model 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 model 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 window 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 dates (por ejemplo, DateDiff), "Tener" e incluso "Agrupar por".

¿Cuál es la alternativa? Personalmente, no necesito un model diferente para el acceso a datos como Linq a Entidades. Prefiero simplemente abrir una window en Visual Studio, ingresar y validar mi SQL, y luego presionar un button para generar o complementar una class 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 class EventData que A) contiene los campos EventID y Title como properties 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 model de objects (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 parameters 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 time 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.

Durante al less 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 class, y SQL se genera sobre la marcha en function de la definición de la class. 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.

Permítanme prolocar esto diciendo que soy un tipo de database 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 objects a tablas y volver es un cambio de context 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 escaping 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 memory 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.

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 less time a escribir las mismas declaraciones SQL una y otra vez y concentrarse en la lógica de la aplicación (con suerte).

En mi humilde opinión, OR / M no se trata solo de 'abstraer el SQL' u ocultar el SQL, o habilitar el soporte de múltiples DBMS.

Le permite concentrarse más en el dominio de su problema, ya que debe dedicar less time 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 model relacional (bien pensado y normalizado) a un expresivo model OO / dominio, entonces creo que está gastando mucho time 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).

El layout 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, filesystems, intercambio, web services, ad infinitum. No puedes usar SQL para esos progtwigs.

También necesita aprender una API diferente para casi cada almacén de datos. Linq les da a todos un objective 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 references si puedo encontrarlas de nuevo.

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

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 time que ahorra, puede centrarse en refinar su model 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 map de identidad que ayuda a evitar cargar elementos una y otra vez, la carga diferida lo ayuda a express el dominio con less plomería y la unidad de trabajo lo ayuda a realizar un seguimiento de los cambios y optimizar las escrituras de la database.

Estoy de acuerdo 100%. Mucho de esto es el resultado del hecho de que las habilidades de encoding de procedimientos y las habilidades de encoding SQL son muy diferentes; y este hecho no es ampliamente reconocido. Entonces, hasta que esa realización llegue, los progtwigdores 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?

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 search la bala mágica, creando la demanda de cosas como Linq para hacer la ilusión (hm, abstracción) de que se ponen usar algo diferente a sus classs 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 database 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 collections.

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 syntax, 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 time. Microsoft tiene una cierta historia de creer que su organización de desarrollo reconocidamente superior puede superar al rest de nosotros, incluidas nuestras memorys 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 superset que nos alejen del metal puro con promises de igual o mejor performance.

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 fue debido a la "falta de adecuación de la impedancia" entre SQL y la progtwigción imperativa, sino únicamente con el propósito de convertirme en agnóstico de plataforma de database. 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 database 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 less 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 ploop. Mi tendencia es tratar de tener una visión a largo ploop 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 less. Por lo tanto, aunque puedo apoyar la idea de desarrollar LINQ to Entities, estoy less dispuesto a apoyar la eliminación de LINQ to SQL simplemente porque LINQ to Entities está disponible. Los objects son geniales para hacer lo que hacen los objects, no hay dudas al respecto … En mi opinión (nuevamente sesgada), surge un problema en el hecho de que las personas ven una 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 database 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 less en la superficie me suena como el patrón anti inversión de abstracción .

So I guess the synopsis for my answer is this: use a hammer if your problem is a nail – use a screwdriver if your problem is a screw.

Dmitry's statement that Developer's don't like SQL may have lot of truth but the solution isn't only ORM. The solution is to hire as part of the development team a Development DBA. In my company my .net development team has an excellent Oracle DBA who does absolutely no production dba work. His role in our team is data modelling, physical db design, creating stonetworking procs, data analysis etc. He is the reason our db side is so clean and performing. All our DB access is via stonetworking procs.

What is a development DBA ? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/

I think the logic behind these things is that the overhead of building and running an SQL statement in the framework layer is insignificant companetworking to overhead in other parts of the system (eg, a HTTP request round trip is orders of magnitude longer).

The advantages – fast development, queries that fit in with the language rather than being escaped strings, etc, often outweigh the disadvantages. If performance is an issue, then you can optimise later.

I don't think that "not needing to know SQL" is a factor. Any decent developer will need to know SQL at some point in their development. The idea of a database abstraction layer is to remove the effort of generating boilerplate code for database queries.

Indeed in our system in Java, I created a code generator utility that took annotated classes and generated a full CRUD API, and handling all those quirky things you pick up over time. Far easier to create your model and annotate it than to slog through writing a DAO. Scale such a tool up and you end up with LINQ or Hibernate or myriad other ORM DB solutions.

I do both database and distributed application programming (web and compiled) and feel like taking the time to develop stonetworking-procedure based data access layers is time well spent. Personally, I prefer to do data modeling and identify the needed procs early in the development process… seems to help uncover design/interface logic/structure issues.

I'm not a big fan of inline database programming (whether the sql code is hand or machine generated). I believe that the database is the foundation of one's application and that taking the time it to hand-code stonetworking procs is worthwhile.

That said, I am intrigued by the OODBMS concept and hope that someday I'll get to work on some in a production environment.

If you want a database to perform as it scales, it has to be designed and normalized according to database relational model best practices.

If you let the Object Model and the ORM dictate your data model, you will just end up with a poor data model which is not normalized and/or contains artifacts from the object model.

1 table = 1 class is a bad idea.

To start with you never, ever, have classes which represent many-to-many or many-to-one link tables. These correspond to child collections in the object model – the links themselves are not objects.

If you treat your database as tables to simply hold your objects in rows (one common approach) and give the application direct access to tables, you are giving up all the benefits of defining an interface layer of database services that the database can use to protect its perimeter.

ORMs have their place, but if you use them to simply persist your objects as designed in your object model, your database will not be a relational database, and it will not be able to be used as one for the purposes of ETL, reporting, refactoring, etc.

There was another question here that asked about ORMs in general. Check that out for some more discussion of whether or not the impedance mismatch is as big a deal as all that.

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.

Codemonkey makes a very good point: stonetworking 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.

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.

Ted Neward wrote a great essay on his take on this subject – that ORM's are the "Vietnam" of computer science…

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

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.

I just discovenetworking 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 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 hundnetworkings of new fields of science have been discovenetworking 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.

Developers don't dislike working with SQL because they are lazy or because it makes them feel 'icky'. They dislike working with SQL because they are smart. They know better than anyone that only someone who specialises in SQL will deliver the highest quality database functionality and that for them to be put into the position of being 'jack of all trades' developers is a suboptimal development strategy.