本帖最后由 pandaidea 于 2009-11-25 18:03:53 编辑

解决方案 »

  1.   


    首先,这种设计是违反数据库设计基本规则的。应该设计成  (日期,价格) 
    其次,“就得变成365条数据……多浪费” 这个说法的依据是什么?你现在的存储方式 
    year 2字节+ month 2字节 + 30天* (dd:nn|) 6字节 = 184 字节而  (日期 date,价格 byte)  则是 30 天 * (3+1) = 120 字节另外查询的效率和速度上完全不可同日而语。
      

  2.   

    我想不出其他的数据结构了,因为需要将后台输入的日期生成1年365天,以年和月分开,每个月31天存成一条数据,并包含了名称,星级,价格,路线。 
    如果不用这种结构的话,就得变成365条数据……多浪费。不符合3NF,记录多不怕,怕的是设计结构不合理如果你只是搜索价格的sql有什么办法在一条语句上对价格进行比较? 搜索框: 
    邮轮名: ______ 油轮价格$: 下拉框: <300        300-400            400-500        >600 出航日期:yyyy/mm/dd        2009/11/25
    日期 价格
    就行了
      

  3.   

    我就怕3W条记录(这个表的作用就是将复杂的5个表的内容总结起来行程一个搜索结果表,专用于前台进行搜索用)。因为那复杂的5条表,一个季节表(大致是 20090101,20090120,w     就是1月1日到20日是旺季),影响到房型表的价格,每种房型都有不同的价格(大致是:香格里拉房  旺季价格500 淡季价格300 平季价格200)再存一个行程id, 行程表大致是 重庆出发带上海。 每个行程里的房型都会产生不同的价格。  而出发表上存了房型id,(数据大致是:2009,11,|2||3||4||5||9||11|)要根据出发日期在季节表里判断属于哪个季节(旺季,淡季,平季),再在房型表里将这个价格取出。然后7788的数据统一成搜索结果表里的“一员”。也就是这个表可以一条sql就达到目的。不需要做复杂的取出,计算,通过结果再取出再计算,最终几次后获得想要的。那样非常缓慢。而如今的搜索结果表,不知还有什么性能更优的数据结构了。
      

  4.   


    如果真的是这样的话,那么我采用:年        月           日           行程id        游轮id       (剩余一些无可重要的静态显示数据)
    忘了说,不光有行程,还有房型……因此是       一艘邮轮,3个行程,4个房型。那么30个油轮就是1576800的数据……真的值么!?!?!?!
      

  5.   


    还是换了种数据存储格式了。存yyyymmdd形式了。价格存另一个字段。