先说一下业务场景，我们在做一个实体桌游游戏，这个游戏是计时付费的，每个桌的价格不一样（有的是100块钱一小时，有的是50块钱一小时），而这个桌游游戏附带有一些其他的增值服务（直播服务等），这些增值服务有的是计时收费的有的是一次性的消费的，而你在玩游戏时还有餐饮服务（可以买酒水视频等等），业务介绍完毕
我之前的设计方案是，把普通商品（可乐，薯片）和桌游游戏都抽象成一种商品，只不过普通商品是XX元/件，而这些游戏是XX元/小时，只是收费方式不同了而已，不过在设计表时，这些需要计时收费的商品比普通商品多了很多额外的字段（开始时间，结束时间等等）在设计表时不知道该怎么设计了。
另一种方案是，游戏就是游戏，本身不应该将其抽象为商品，有单独的表来记录游戏信息（开始时间，结束时间，得分啊什么的），而把可乐雪碧这样的普通商品作为商品进行存储，而把直播这些的增值服务作为游戏的扩展信息，在每张游戏表中多几个字段（是否开启直播服务等），但是这几个字段的价格貌似就不能在数据库中定义了，只能写在程序或配置文件里了。
等最后结算价格的时候，将普通商品消费的订单与游戏信息分别计算，最后融合在一个总结算订单内，展示给用户即可
现在问题是，哪一种方案会好一些？我个人倾向第二种方案，毕竟以后可能需要扩展更多的游戏信息，比方说，游戏的游戏的一些比分啊，数据等等，但是游戏的增值服务的价格不知道该怎么记录，如果有的增值服务都一个价格还可以，直接写死在程序或配置文件中就ok了，但是如果每个游戏桌的服务价格不一样就不知道该怎么设计了。。。
你第二个方案里面说的那个单独开给游戏的表是每一次消费记录表，你应该还有一个游戏类型之类的表用来存放每种桌游的信息啊，价格也是在这张表里面存储即可
我的方案：
-
游戏是游戏，游戏桌是游戏桌，这两个要分成两个实体来考虑
游戏桌是一种商品，不同的游戏桌价格不同，在数据库里的记录也不同，用户每次消费的是游戏桌、食品、直播等
游戏是另外一种实体，它的单位是局。游戏跟跟游戏桌是多对一的关系，每个游戏桌一天会顺序开展多场游戏
-
订单分总订单和子订单，和你说的差不多:
总订单和前面说的游戏一对一的关系
总订单下属几项子订单，比如哪个游戏桌，那些食品，还有直播等等
订单应该还有各种折扣或优惠券、抵用券的关联信息
再回头说游戏实体，这个实体就会记录你说的开始结束时间、得分什么的。至于是否开启直播等各种flag，可以用一个整数来表示，每个flag是这个整数里面的一位，这样可以随便扩展。
最后应该要设计用户表，同时要记录用户和游戏的关联表，用户的数据分析对这样的产品会十分重要。比如什么年龄段的人喜欢什么游戏，用户回头率多高、用户喜欢点哪些食品等等