准备用SQL2005的UDT,把数据直接存为对象,不进行O/R映射。查询上如何处理较好呢? 100superhasty]

发布时间:2016-12-11 20:17:09 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"准备用SQL2005的UDT,把数据直接存为对象,不进行O/R映射。查询上如何处理较好呢? 100superhasty]",主要涉及到准备用SQL2005的UDT,把数据直接存为对象,不进行O/R映射。查询上如何处理较好呢? 100superhasty]方面的内容,对于准备用SQL2005的UDT,把数据直接存为对象,不进行O/R映射。查询上如何处理较好呢? 100superhasty]感兴趣的同学可以参考一下。

最大的好处,代码量减少明显、开发效率大大提高: 想象一下,如果我把一个用户的几十个字段作为一个对象存在数据的一个字段中,存储修改的时候就不必编写又长又复杂的SQL语句了。 现在担心的是,如何提高查询效率?因为数据库里面存储的都是对象(可以认为每一条记录除了ID,剩下的字段,主要就是一个对象)。 目前的思路是: 如果客户端要按照对象的某一个或者几个字段查询,可以用CLR编写一个存储过程,在存储过程中查询。但在对象集合中查询效率可能还是有问题,尤其是相比SQL的Select...Where...的效率。 另外一个方式是,将需要查询的字段还是存为单独的字段,这样可以使用Select...Where了。但不太甘心这种折中的方式。

2005还没有具体用过!收藏了!

楼主还真有研究……我帮你定一下,主要是向你学习,哈哈

我当时想把对象以xml形式存进一个字段但是考虑查询效率肯定很低所以就放弃了 所以还是要ORM啊 希望跟楼主一起讨论 QQ:65739394 验证ORM msn [email protected]        。

把一个对象直接存储在数据库中, 与数据关系产生了冲突, 而sql server是关系型数据库, 个人觉得不太适合.

这样是不是违背了关系型理论

呵呵,我没考虑那么多,主要考虑满足功能和性能的要求、使用方便。

不要使用 UDT 来对复杂的业务对象(如雇员、联系人或客户)进行建模。您将会陷入 UDT 的所有列限制(如,8KB 大小限制、索引限制)和在更新 UDT 值时更新整个值的不利方面。对于复杂类型,UDT 不是合适的数据建模抽象;因此对于这种情况,最好使用中间层对象相关映射技术。

2005还得研究一下.

学习

适可而止了,要看整个项目的设计原则。从便捷性来看可以大大提高开发效率,特别用ADO.Net来访问数据库了,当然数据库的整体性能会有所下降。

2005没用过,也许跟oracle中的对象差不多吧

应该不是什么新技术. 我隐约记得用 c#的时候,我就把一个对象序列化存到数据库里去了,好像当初用的是 二进制类型. 不过挺别扭的.搞得不像是关系型数据库倒像是个仓库. ----------------- http://chinadba.cn 最具实战经验的数据库优化,管理,设计,培训网站.

上一篇:终于看明白了什么叫做数据挖掘 0CSDN]
下一篇:sql2005的備份數據庫能否在SQL2000恢復?SQL2000的備份數據庫在SQL2005恢復就可以了麼? 20yuhuahuang]

相关文章

相关评论