求问我这个数据库该怎么设计?

发布于 2022-09-03 13:01:40 字数 694 浏览 12 评论 0

先说一下业务场景,我们在做一个实体桌游游戏,这个游戏是计时付费的,每个桌的价格不一样(有的是100块钱一小时,有的是50块钱一小时),而这个桌游游戏附带有一些其他的增值服务(直播服务等),这些增值服务有的是计时收费的有的是一次性的消费的,而你在玩游戏时还有餐饮服务(可以买酒水视频等等),业务介绍完毕

我之前的设计方案是,把普通商品(可乐,薯片)和桌游游戏都抽象成一种商品,只不过普通商品是XX元/件,而这些游戏是XX元/小时,只是收费方式不同了而已,不过在设计表时,这些需要计时收费的商品比普通商品多了很多额外的字段(开始时间,结束时间等等)在设计表时不知道该怎么设计了。

另一种方案是,游戏就是游戏,本身不应该将其抽象为商品,有单独的表来记录游戏信息(开始时间,结束时间,得分啊什么的),而把可乐雪碧这样的普通商品作为商品进行存储,而把直播这些的增值服务作为游戏的扩展信息,在每张游戏表中多几个字段(是否开启直播服务等),但是这几个字段的价格貌似就不能在数据库中定义了,只能写在程序或配置文件里了。

等最后结算价格的时候,将普通商品消费的订单与游戏信息分别计算,最后融合在一个总结算订单内,展示给用户即可

现在问题是,哪一种方案会好一些?我个人倾向第二种方案,毕竟以后可能需要扩展更多的游戏信息,比方说,游戏的游戏的一些比分啊,数据等等,但是游戏的增值服务的价格不知道该怎么记录,如果有的增值服务都一个价格还可以,直接写死在程序或配置文件中就ok了,但是如果每个游戏桌的服务价格不一样就不知道该怎么设计了。。。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

月朦胧 2022-09-10 13:01:40

你第二个方案里面说的那个单独开给游戏的表是每一次消费记录表,你应该还有一个游戏类型之类的表用来存放每种桌游的信息啊,价格也是在这张表里面存储即可

狼性发作 2022-09-10 13:01:40

我的方案:

  1. 游戏是游戏,游戏桌是游戏桌,这两个要分成两个实体来考虑

    1. 游戏桌是一种商品,不同的游戏桌价格不同,在数据库里的记录也不同,用户每次消费的是游戏桌、食品、直播等

    2. 游戏是另外一种实体,它的单位是局。游戏跟跟游戏桌是多对一的关系,每个游戏桌一天会顺序开展多场游戏

  2. 订单分总订单和子订单,和你说的差不多:

    1. 总订单和前面说的游戏一对一的关系

    2. 总订单下属几项子订单,比如哪个游戏桌,那些食品,还有直播等等

    3. 订单应该还有各种折扣或优惠券、抵用券的关联信息

  3. 再回头说游戏实体,这个实体就会记录你说的开始结束时间、得分什么的。至于是否开启直播等各种flag,可以用一个整数来表示,每个flag是这个整数里面的一位,这样可以随便扩展。

  4. 最后应该要设计用户表,同时要记录用户和游戏的关联表,用户的数据分析对这样的产品会十分重要。比如什么年龄段的人喜欢什么游戏,用户回头率多高、用户喜欢点哪些食品等等

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文