酒店价格表结构这样设计是否合理

[wyumening]

表名为Hotel_Rates, 表结构如下：
Rates_id int 主键ID
Rooms_cod nvarchar（50） 主库房型ID
Hotel_id int 子库酒店ID
Hotel_cod nvarchar（50） 主库酒店ID
Rooms_id int 子库房型ID
Duration int 年月，格式如：201101
UpdateTime varchar(50) 价格更新时间
Gys_id nvarchar(100) 供应商ID
然后是价格 共31个字段，名称分别为 Price_1到Price_31
Price_1 varchar（50） 存储当天的价格 数据格式为 价格#早餐类型#房间数#出售状态 例如 150#0#0#0

查询价格的时候，如果是2014-9-24的话，就根据酒店id,房型id,供应商id,查询到Duration为201409，然后得到Price_24这个字段的值，但是在实际操作的时候，这个酒店价格表是和房型表，酒店表，供应商表inner join 查询的，数据量一大就出问题了，
例如： 当查询的日期条件为9月20日和9月21日时，查询速度很慢，要一分钟左右才出结果，查询执行计划 ：提示要创建的索引为：CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[Hotel_Rates] ([Duration])
INCLUDE ([Hotel_cod],[Rooms_id],[Price_20],[Price_21],[Gys_id])

但问题是查询的日期条件是不固定的，在实际的操作中，可能查询的字段是Price_1到Price_31的任意多个字段，这样是无法创建固定的索引来优化的，是不是表结构要改呢？如果要改应该如何改呢？

[wyumening]

引用 8 楼 Tiger_Zhao 的回复:

价格按时间段设置比较符合业务啊！ 而且价格和状态是由不同的角色更新的，分开来容易操作。

可能是项目不同吧，我现在做的这个项目，价格和状态是同一个角色更新的。。。既然这样的话，价格和状态不分表也可以，只要按天来存储数据，然后定期删除过期的数据就行了吧？

[Tiger_Zhao]

操作时是一个房型一段时间统一修改价格的吧。
单表就会修改许多记录，要处理的数据页比较多，理论上是对性能有影响的。
而分表后在价格表中只修改一两条记录，这个性能比较稳定。

[wyumening]

引用 11 楼 Tiger_Zhao 的回复:

操作时是一个房型一段时间统一修改价格的吧。 单表就会修改许多记录，要处理的数据页比较多，理论上是对性能有影响的。 而分表后在价格表中只修改一两条记录，这个性能比较稳定。

操作的时候，价格和状态都可以修改的，也就是说如果不分表，按天来存放价格的话，如果修改10天的价格，就会修改十条记录，如果价格和状态分表的话，用户要修改时，修改10天的价格，那么价格表就会有10条记录被修改，如果用户同时修改了状态，那状态表中一样有10条记录要修改的，因为状态指的是单个房型的状态，是出售还是停售，如果分表的话价格表有十万条记录，那么状态表也一样有10万条记录的

[Tiger_Zhao]

改成一天一条记录是最规则最容易使用的：
Duration 改为日期
Price_1到Price_31 把 价格#早餐类型#房间数#出售状态 都拆成独立的字段。

[wyumening]

引用 1 楼 Tiger_Zhao 的回复:

改成一天一条记录是最规则最容易使用的： Duration 改为日期 Price_1到Price_31 把 价格#早餐类型#房间数#出售状态 都拆成独立的字段。

以天来存放记录的话，到后面数据量会很大的，还是说一开始的时候就创建分区表更好些？

[leeya66]

最主要的，你的价格影响因素是哪些要想清楚。 我理解了一下应该是日期、房间类型、酒店类型 这3个因素。 那么自然的，你这份价格表就至少应该有这4个字段 日期(yy-mm-dd)，房间类型，酒店类型，价格

[KeepSayingNo]

建议单独搞个价格表吧，价格表通过酒店ID和酒店表进行关联，价格表的设计如下 酒店ID 房间ID 价格 早餐类型 出售状态

[wyumening]

引用 4 楼 dotnetstudio 的回复:

建议单独搞个价格表吧，价格表通过酒店ID和酒店表进行关联，价格表的设计如下 酒店ID 房间ID 价格 早餐类型 出售状态

那还是按具体的哪一天来存放记录？到后面数据量会很大的，还是说一开始的时候就创建分区表更好些？

[Tiger_Zhao]

引用 2 楼 wyumening 的回复:

[quote=引用 1 楼 Tiger_Zhao 的回复:] 改成一天一条记录是最规则最容易使用的： Duration 改为日期 Price_1到Price_31 把 价格#早餐类型#房间数#出售状态 都拆成独立的字段。

以天来存放记录的话，到后面数据量会很大的，还是说一开始的时候就创建分区表更好些？[/quote] 应该分表。 实际上价格不会天天变，所以可以做成日期范围的，这样价格表的记录数不会很多。 至于出售状态，一天一个记录，虽然记录数比较多，但是实际经常操作的就是最近一段时间的记录，状态表性能问题不大。 你有多少G的数据就要用到分区了？ 定期删除过期数据就可以了。

[wyumening]

引用 6 楼 Tiger_Zhao 的回复:

[quote=引用 2 楼 wyumening 的回复:] [quote=引用 1 楼 Tiger_Zhao 的回复:] 改成一天一条记录是最规则最容易使用的： Duration 改为日期 Price_1到Price_31 把 价格#早餐类型#房间数#出售状态 都拆成独立的字段。

以天来存放记录的话，到后面数据量会很大的，还是说一开始的时候就创建分区表更好些？[/quote] 应该分表。 实际上价格不会天天变，所以可以做成日期范围的，这样价格表的记录数不会很多。 至于出售状态，一天一个记录，虽然记录数比较多，但是实际经常操作的就是最近一段时间的记录，状态表性能问题不大。 你有多少G的数据就要用到分区了？ 定期删除过期数据就可以了。[/quote] 删除过期数据的话按年来就可以了吧？用户要查看的日期最多是一年之内的，分表是说分为价格表和状态表？这个记录数并没有减少呀？为什么要分表呢？

[Tiger_Zhao]

价格按时间段设置比较符合业务啊！
而且价格和状态是由不同的角色更新的，分开来容易操作。

[xiaodongni]

不用一天一行记录吧就记录变化就好了。 比如20140901 价格100， 然后在0908号改成110 你就2行数据 价格 生效日期 100 20140901 110 20140910 有改变就生成一条记录啊

[Tiger_Zhao]

价格表不按天，按(开始日期,结束日期,价格)存放，记录要少的多。

[KeepSayingNo]

引用 5 楼 wyumening 的回复:

[quote=引用 4 楼 dotnetstudio 的回复:] 建议单独搞个价格表吧，价格表通过酒店ID和酒店表进行关联，价格表的设计如下 酒店ID 房间ID 价格 早餐类型 出售状态

那还是按具体的哪一天来存放记录？到后面数据量会很大的，还是说一开始的时候就创建分区表更好些？ [/quote] 看了后面的讨论，知道你这个价格会有时修改的，但是又想把以前的记录保存，这样的话一年下来也没多少记录，如果你确实觉得不放心的话，可以按年分表存储。或者采用分区表

[wyumening]

最后还是改成一天一条记录了，这样到后面的查询优化做起来更简单些，Duration 改为日期 Price_1到Price_31 把 价格#早餐类型#房间数#出售状态 都拆成独立的字段，感谢大家的回答，结贴了