What a strange article. It starts off nice enough, describing a handy pattern that lots of us use to handle individual records for CRUD. But then it construct

What a strange article. It starts off nice enough, describing a handy pattern that lots of us use to handle individual records for CRUD. But then it constructs this giant crazy strawman of ways that you could do a bunch as ridiculous silly things, and how if you did those crazy things it would completely wreck your performance. Certainly it would. But nobody would ever do any of those crazy things. My version of this thing, for instance, makes a point of wrapping all your Stored Procedures for you, and provides methods to construct single items or lists of them from a dataset that you hand it. That solves roughly 100% of the panicky disaster scenario that the author predicts. (The other 0% is the giant (also usually 0%) performance hit you get from pulling all six columns of data from a table when you only need two of them.) So yeah, don't recursively enumerate the entire database three times when you can write a query with a Join in it. But don't make up silly query languages that aren't SQL either. Just do what sensible people do with this data pattern and you'll find that it works nicely.