1、最近看之前的设计有些困惑，一个最简单的需求，例如价格、状态，是按照天来存储的，
类似这样：id hotel date price 这几列，发现如果单个日期存一条，如果设置1年价格要存365条，这个数据量增长就比较大了；
然后现在的设计是这样的，id hotel startDate endDate price，连续日期价格相同的存一条，这样从业务上能减少不少数据量，但是另一个问题出来了，当修改价格的时候就异常费劲了，多个日期的、多个hotel的，多日期多hotel多价格的，就需要拆、拆、拆然后merge、merge、merge，复杂还容易出错
这个应该是一个非常常见的模型了，咨询下各位大神有什么好的设计没有？如果再增加一个price2列，岂不是更麻烦了，想想就头疼
可以嘗試表格記憶體兩個資料：價格，持續時間（到幾月幾號幾點幾分），不過查詢的時候可能要做一步比較。
把價格和時間拆出去到另外一張表 關聯這個hotel即可;
price表可以以每天作為一條數據