As I see it this could really help with the organisation of data. Think about a sales order, this can be created as an object with properties (Order number, Item Purchased, Quantity, Price) and methods (create, delete, hold, archive, fulfil).

The underlying RDBMS logic behind these properties and methods could be highly dispersed, with an order itself spanning 2 tables and the details coming from more (eg customer number can be an FK to a customer table, Item Numbers another FK to an Item table etc). Essentially by doing all the back end relational work and exposing the Sales Order and it's properties and methods you could save many many weeks of work.

So I'll take issue with the previous post - I currently have an in house sales team taking orders. The application makes use of the Sales Order object (in effect, although I'm not that organised yet in reality). Say I wanted to uplift that functionality to the web - what is better, spending maybe an extra 20% of my time organising my data in the first place and saving 50% of my development time on the web by already having this object to play with, or defining every single last transaction I need to use to create a sales order again?

As far as Steves point about table level access is concerned, I agree. Programmers simply can't be trusted with the relational model, it's like getting the builders in to make an ice sculpture.... I never liked the idea of CLR either, and I think that a good DBA will have to understand this stuff to a good enough level to present the developers with the finished data object model. I don't count myself as a good DBA and I may have missed the point, looking forward to a learning experience 😉