David

I have been coding to databases for nearly 30 years. (I don't come from America(nth, sth or in between))

And I agree with you about most "designers". They need a re-education of what programming is!!

I think nHiberate and Entity Framework are better solutions(tools) than using stored procedures to maintain a database. Although I have reservations about their ability to Create a database or tables therein.

But you need to know the RDBMS to make good design decisions (eg refain from Views in SQL SERVER, embrace them in Oracle; same as with CURSORS. not for SQL SERVER but great in ORACLE) and you need to know the business domain to be able to optimise those databases for best effect.(eg look how a CLUSTERED indexes affect Inserts and therefore which keys to use as CLUSTERED, most of the time never the auto-generated number key.)

But if programmers use these data modelling tools they will not return to SPs. Except when the modelling tools can't do what a SP/Function can, or for elaborate reporting.

So I suppose that my approach to build Enterprise frameworks and educate/mentor young programmers to take a life approach to their own learnings. I just don't like spoon feeding people, even if it is good for them.

As far as management... Don't get me started else this will actually get much longer and dirtier.

As I said before, in general your Idea is good but it shouldn't impose a non-industry naming convention, have the ability to swap out tiers(refactor) for a better solution, be scalable(application farming), be expandable(add more features, coding and datastore), be able to be comunicated with(services) and most of all, be totally maintainable(no black boxes).

I would rather start programmers off by teaching these things than to hide these things from them.

Best of Luck

GregJF