日期不同而价格不同的数据库设计，是不是不应该用开始结束时间？

Question

现在做的酒店的价格，某个日期会把价格变动。数据库结构大长这个样子。忽略大多数字段，room_type是房型的 id，价格是对他进行绑定。

+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| id         | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| hotel_id   | int(11)          | NO   |     | NULL    |                |
| room_type  | int(11)          | NO   |     | NULL    |                |
| price      | decimal(10,2)    | NO   |     | NULL    |                |
| start_date | date             | NO   |     | NULL    |                |
| end_date   | date             | NO   |     | NULL    |                |
+------------+------------------+------+-----+---------+----------------+

这个是插入时我认为会出现的情况：

https://i.loli.net/2018/08/29...
这是图片地址, sf 会缩小地址

总共有四种可能（图中的三种 + 查不到记录，直接插入数据），每一个可能，因为区间贴合不贴合的问题又分出四种(贴合，左贴合右不贴合，右贴合左不贴合，两边都不贴合)。总共就是 3*4 + 1

---

是不是这种问题在数据库就有更好的解决方法？望做过的朋友指点指点。

---

重新上传了图片，之前会被模糊掉

---

如果不在插入时做处理。

                                          130$   
                                 +-----------------+
                                 |                 |
                                 v                 v
                      150$
     +----------------------------------------------------------+
     |                                                          |
     v      120$                                                v
+-------------------+           
|                   |    
v                   v           
  +--------------------------------------------+
 开始日期                                      结束日期

我要查询开始日期到结束日期的价格，实际上是，有三段分别是 120 ~ 150 ~ 130
如果不在插入的时候分别让他们的开始到结束时间不冲突，你打算怎么做。

Answer 1

1. 该表我觉得没有必要加begin_date、end_date字段
2. 对于价格随时间变动的应该吧price、begin_date、end_date和相应的房型组成一个新的表
3. 查询的时候根据当前或者选中的时间查询2中的表，命中则使用2表中的价格，未命中则使用1表中的默认价格。
4. 这样一个房型可以有多个价格区间，可以达到定制某个时间段的价格，甚至可以叠加，比如7月-10月价格100，但是七夕价格10，取最新的值就好了，或者标记置顶的值。

Answer 2

理论问题都不大

尽量抽出理论实体对象和根据业务形态做

比如，价格跟着房型，房型可以根据日期定价，最终用户下单的价格是一条订单记录，都可以抽象成一个具体实体表！

订单记录完整记录信息:
用户信息，房型，房间号，下单日期，优惠等等

具体查询相关的，我就不就具体了，因为不了解你的实际业务