>>But ORM is often overengineered for simple tasks and was sometimes to slow when facing large datasets. Have not checked heavy usage in the last 4 years - might be coming from stale samples. But KISS has its benefits - I try for "rectangular" DB setup - yes NoSQL/document data may save some time and money, but should live in a tiny part of otherwise rectangular data. Forcing that rectangular directly into ORM memory IMO is missing out on possible HW caching benefits.
>
>I think where some of the ORM thinking shines is with disconnected data sets where you can deal with "graphs" of data and have local and remote caches. Ideablade was doing this stuff a while back with the early version of EF and then it sort of became part of the product (I think Ward Bell was basically just previewing what his friends on the EF team were doing pre-release.) I can see speed advantages if properly architected but I think those advantages would really be in asynchronous environments rather than fully connected client server apps.

Using normal textual/numeric data, fully ACK. If blob/picture/doc/varchar[not tiny] come into play, it can become "feelable" in 1GB-connected CS apps.