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

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'

以上设计在存储数据时很方便,产品增加属性我不需要修改表结构;
但计算时有些麻烦,各位这样的设计是否可取?特别是有类似尝试的朋友能给写意见或建议!
亟待您的回复。
...全文
153 10 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
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来做,初步估计这种设计可以满足报表需求;但就怕估计不足,到系统实现完成了再发现有什么无法处理的东西就惨了。

34,838

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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