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

superhasty 2005-11-19 07:17:12
最大的好处,代码量减少明显、开发效率大大提高:
想象一下,如果我把一个用户的几十个字段作为一个对象存在数据的一个字段中,存储修改的时候就不必编写又长又复杂的SQL语句了。

现在担心的是,如何提高查询效率?因为数据库里面存储的都是对象(可以认为每一条记录除了ID,剩下的字段,主要就是一个对象)。

目前的思路是:
如果客户端要按照对象的某一个或者几个字段查询,可以用CLR编写一个存储过程,在存储过程中查询。但在对象集合中查询效率可能还是有问题,尤其是相比SQL的Select...Where...的效率。

另外一个方式是,将需要查询的字段还是存为单独的字段,这样可以使用Select...Where了。但不太甘心这种折中的方式。
...全文
337 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
javanow 2005-12-27
  • 打赏
  • 举报
回复
应该不是什么新技术.

我隐约记得用 c#的时候,我就把一个对象序列化存到数据库里去了,好像当初用的是 二进制类型.

不过挺别扭的.搞得不像是关系型数据库倒像是个仓库.

-----------------
http://chinadba.cn
最具实战经验的数据库优化,管理,设计,培训网站.
zyqqzy 2005-12-27
  • 打赏
  • 举报
回复
2005没用过,也许跟oracle中的对象差不多吧
guxiaobo1982 2005-12-27
  • 打赏
  • 举报
回复
适可而止了,要看整个项目的设计原则。从便捷性来看可以大大提高开发效率,特别用ADO.Net来访问数据库了,当然数据库的整体性能会有所下降。
Snoworld 2005-12-23
  • 打赏
  • 举报
回复
2005还得研究一下.
aderly 2005-12-23
  • 打赏
  • 举报
回复
不要使用 UDT 来对复杂的业务对象(如雇员、联系人或客户)进行建模。您将会陷入 UDT 的所有列限制(如,8KB 大小限制、索引限制)和在更新 UDT 值时更新整个值的不利方面。对于复杂类型,UDT 不是合适的数据建模抽象;因此对于这种情况,最好使用中间层对象相关映射技术。

mislrb 2005-12-23
  • 打赏
  • 举报
回复
学习
superhasty 2005-12-19
  • 打赏
  • 举报
回复
呵呵,我没考虑那么多,主要考虑满足功能和性能的要求、使用方便。
jijl2001 2005-12-19
  • 打赏
  • 举报
回复
这样是不是违背了关系型理论
zjcxc 2005-12-14
  • 打赏
  • 举报
回复
把一个对象直接存储在数据库中, 与数据关系产生了冲突, 而sql server是关系型数据库, 个人觉得不太适合.

lxw99 2005-12-07
  • 打赏
  • 举报
回复
我当时想把对象以xml形式存进一个字段但是考虑查询效率肯定很低所以就放弃了
所以还是要ORM啊
希望跟楼主一起讨论
QQ:65739394 验证ORM
msn lixuewu7612145@hotmail.com 。

lovcal 2005-11-30
  • 打赏
  • 举报
回复
楼主还真有研究……我帮你定一下,主要是向你学习,哈哈
天地客人 2005-11-20
  • 打赏
  • 举报
回复
2005还没有具体用过!收藏了!

6,129

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server 新技术前沿
社区管理员
  • 新技术前沿社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧