• I think you've hit the nail on the head here Tony. I don't agree with either of the wild fringe groups. I think that well designed apps take advantage of strengths in the areas of development that best benefit the business problem, not simply use tool X or paradigm Y to develop the system.

    Unfortunately, I'm now working on a pretty major undertaking that is adopting, whole-heartedly, one of the wild fringe group approaches. We no longer have a database. We have an information persistance layer. Funny thing is, it's still on a relational database management system, SQL Server. I don't understand how ignoring the database will make any issues with it go away?

    You mentioned how Microsoft is causing the problem. Part of the issue coming out of MS are the apps they're developing. One of the VP's in charge of about half our development teams keeps pointing at how MS developed their CRM application. It's largely, but not completely, a dumb database. He just keeps saying that if MS does it, it must be OK. It's hard to argue with that except to point out that the system, while it doesn't use stored procedures, has tons of code on the database in encrypted views that do a lot of the work and it has a clearly defined data model that drives the engine... It's all falling on deaf ears because there is a hefty percentage of developers that believe the days of having to deal with all that messy TSQL stuff and confusing normalization are behind them.

    I just don't see it.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning