在上一节中，我们看到了UDT带来了新的希望。总结一下开发历程：
1. 创建UDT，定义数据元素
2. 创建表，定义表关系，创建Triger
3. 创建中间层，可能是基于CLR的SP/Function或者是外部的程序。
4. 创建客户端。
问题：
要不要OR Mapping了？SQL2005加入了CLR支持，即使我们用CLR编写了SP/UDT, 但是，不论在SP中还是外部数据层，都需要通过SQL作为中介来访问数据。能不能通过Remoting或者其它方式，直接得到SP/表/DB的强类型引用，直接操作数据库？比如：
DB db = DB.Instance;
string r1 = db.MyStoredProcedure1(p1,p2); //call SP.
int r2 = db.MyFunction1(p1,p2); //call function
DB.MyUserCollection tbl = db.MyUser.Select(“name = 'abc'“); //select
MyUser user = tbl[0];
string postCode = user.Address.PostCode; //表应该是OR Mapping的。
暂时来看，数据库应该提供对逆向代码生成。
作为设计者，我觉得未来版本的数据库应该把自己看成OO数据库，应该具有一下特征：
1. 在数据库设计上直接从对象开始设计。
2. 对象持久化为表。关系数据库表作为内部运作机制，不对外。
3. 没有UDT，一切都是UDT，
4. 对象映射成XML还是表还是普通字段只是持久化属性Attribute的问题。
5. 索引应该根据查询智能创建，失效。
6. 数据库可以被作为对象直接引用。
7. 数据库权限采用CLR统一的Principal
8. 数据库和虚拟机在使用上无缝合并，成为一个系统。
1. 创建UDT，定义数据元素
2. 创建表，定义表关系，创建Triger
3. 创建中间层，可能是基于CLR的SP/Function或者是外部的程序。
4. 创建客户端。
问题：
要不要OR Mapping了？SQL2005加入了CLR支持，即使我们用CLR编写了SP/UDT, 但是，不论在SP中还是外部数据层，都需要通过SQL作为中介来访问数据。能不能通过Remoting或者其它方式，直接得到SP/表/DB的强类型引用，直接操作数据库？比如：
DB db = DB.Instance;
string r1 = db.MyStoredProcedure1(p1,p2); //call SP.
int r2 = db.MyFunction1(p1,p2); //call function
DB.MyUserCollection tbl = db.MyUser.Select(“name = 'abc'“); //select
MyUser user = tbl[0];
string postCode = user.Address.PostCode; //表应该是OR Mapping的。
暂时来看，数据库应该提供对逆向代码生成。
作为设计者，我觉得未来版本的数据库应该把自己看成OO数据库，应该具有一下特征：
1. 在数据库设计上直接从对象开始设计。
2. 对象持久化为表。关系数据库表作为内部运作机制，不对外。
3. 没有UDT，一切都是UDT，
4. 对象映射成XML还是表还是普通字段只是持久化属性Attribute的问题。
5. 索引应该根据查询智能创建，失效。
6. 数据库可以被作为对象直接引用。
7. 数据库权限采用CLR统一的Principal
8. 数据库和虚拟机在使用上无缝合并，成为一个系统。
