This article is another classic case of confusing the logical schema with the physical implementation. The future of DBs is allowing more separation of the two, not less, and more end-user choice over a physical implementation that matches up well with actual access patterns.
>> "Nor do I expect developers to understand SQL."
I do not agree. I expect all of my developers to be proficient in both C# and SQL. I expect them to be able to properly design object oriented solutions and entity relations. And I expect them to know better than to use HTML tables for general purpose layout. There is no such thing as "one's natural paradigm".
For simple apps, yes. But actually I was surprised to find out that they have been on and off plans in attempt to kill linq2sql and actually if you inspect the produced sql code(out of the box) .. well it can use a lot of optimizations.
I do think o/r mappers are the way to go, although having better tools does not mean that you should start handwaving when it comes to db internals.
Maybe if all you're doing is writing silly blogging software, then you can get away with that. I need to develop apps the report live on nation-wide sales and inventory data, down to the individual shipment. You start dealing with a database intended to hold 10, 20 years of warehoused data, application languages turn into a blur in the background.
Totally not the point. C# is just an example of an application language. The point is that there is no reason why a developer can't master the full stack.
11 comments
[ 14.3 ms ] story [ 283 ms ] threadFolks: simply because you can write SQL does not mean that you have something insightful to say about ACID
I do not agree. I expect all of my developers to be proficient in both C# and SQL. I expect them to be able to properly design object oriented solutions and entity relations. And I expect them to know better than to use HTML tables for general purpose layout. There is no such thing as "one's natural paradigm".
I do think o/r mappers are the way to go, although having better tools does not mean that you should start handwaving when it comes to db internals.
Also any web app that is not using some form of OOP must be a very small or very confusion application (confusing to modify not use).