• 主页
  • 基础类
  • 应用实例
  • 新技术前沿

纵向存储的数据在计算时遇到问题

smile9961 2009-07-21 11:00:22
我用同一个表来保存所有产品的一些属性信息;但这些属性会因产品的不同有增有减少。
所以我将表结构设计如下:

ProductProperty
(
ProductId int,
PropertyId int,
PropertyValue nvarchar(50),
PropertyDataType nvarchar(50) --string, int, datetime
)

如果需要根据产品的一些属性做些计算,
就需要将用于计算的属性取出来,
即用一个表来返回一个属性进行计算,並且屬性ID需要写死;类似这样:

select PropertyValue from ProductProperty where PropertyId = 'Property1'

以上设计在存储数据时很方便,产品增加属性我不需要修改表结构;
但计算时有些麻烦,各位这样的设计是否可取?特别是有类似尝试的朋友能给写意见或建议!
亟待您的回复。
...全文
74 点赞 收藏 10
写回复
10 条回复
叶子 2009年07月21日
两者有弊有利 很难两全!
回复 点赞
tim_spac 2009年07月21日
需要在“计算效能”与“系统稳定性”间权衡
(通常我会优选稳定。)
回复 点赞
smile9961 2009年07月21日
楼上说得没错,我现在就是觉得计算时处理起来麻烦;或者,不这样设计,有其他好的办法处理这个问题?
回复 点赞
仙道彰 2009年07月21日
友情帮顶
回复 点赞
sdhdy 2009年07月21日
这样做,数据运算不太好实现。
回复 点赞
smile9961 2009年07月21日
非常感谢各位的热心解答;相信将来所遇到的问题能迎刃而解!
回复 点赞
红街咖啡 2009年07月21日
帮顶一下。
回复 点赞
tim_spac 2009年07月21日
现有的机制抽象度很高--一般不会出现6L顾虑的问题。
回复 点赞
hery2002 2009年07月21日
表设计上应该没有什么问题.
如果是不太复杂的计算逻辑的话,应该写函数来处理你的计算逻辑就可以了.传入ProductId,PropertyId和PropertyDataType三个参数,返回计算结果作为一列来展示.
回复 点赞
smile9961 2009年07月21日
因计划后面的报表用Reporting Service来做,初步估计这种设计可以满足报表需求;但就怕估计不足,到系统实现完成了再发现有什么无法处理的东西就惨了。
回复 点赞
发动态
发帖子
MS-SQL Server
创建于2007-09-28

1.4w+

社区成员

25.3w+

社区内容

MS-SQL Server相关内容讨论专区
社区公告
暂无公告