请教一下对于(article-photo-video)和(tag-comment)多个多态关联优缺点问题

  1. 主要表关系
  • tag 标签表 与 (Article、photo、video)表 多对多 多态
  • favorites 收藏表 与 (photo、video)表 多对多 多态
  • comment 评论表 与 (Article、photo、video)表 多对多 多态
  • statis 统计表 与 Article、photo、video)表 一对多 多态
  1. 那么问题就来了
  • 这样处理可以让各种场景下的相同属性统一在一个表内管理,减少字段多余
  • 但是如果数据量多了、访问量多了之后呢,比如评论,文章的评论每日新增量远远多余其他场景的时候,储存查询都需要在相同表操作数据,每次执行mysql的时间也会增多,这种情况下我能想到的是把文章的评论单独对应关系,
  • 所以:我就开始好奇起来,那么建立多态的优点都有哪些呢,相对于数据量和访问量多的时候多态场景下和每个场景单独对应下那种方式更好呢;然后我就找了好多资料,都是简要怎么使用,没有找到优化选择问题,所以请教一下各位大佬们在百忙之后能否为我解答一下呢?
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
最佳答案

多态的模型关联有点就是简单,容易理解。每个场景用独立的关联其实并不会有明显的性能提升(如果你的数据体量真的很大的话)。

比如某个热门视频有 300W 的点赞,15W 的评论时,多态5s查询和单独表3s查询,虽然从数字上看时快了不少,但是对于用户来说依然时难以接受的。

在速度上要想有明显的提升,这时候你肯定得上缓存啊,但是就要考虑数据一致性,缓存的持久化等等……

我的建议是先按最简单的方案来,遇到性能瓶颈了再去做优化。实际工作中经常看到号称用户体量如何,实际上线后80%的请求量来自开发团队和测试团队。 :joy:

3年前 评论
sendwarm (楼主) 3年前
讨论数量: 4

多态的模型关联有点就是简单,容易理解。每个场景用独立的关联其实并不会有明显的性能提升(如果你的数据体量真的很大的话)。

比如某个热门视频有 300W 的点赞,15W 的评论时,多态5s查询和单独表3s查询,虽然从数字上看时快了不少,但是对于用户来说依然时难以接受的。

在速度上要想有明显的提升,这时候你肯定得上缓存啊,但是就要考虑数据一致性,缓存的持久化等等……

我的建议是先按最简单的方案来,遇到性能瓶颈了再去做优化。实际工作中经常看到号称用户体量如何,实际上线后80%的请求量来自开发团队和测试团队。 :joy:

3年前 评论
sendwarm (楼主) 3年前

我也在这个问题上犹豫了很久,不知道字段公用好还是独立表好

3年前 评论
  • 多态关联主要的使用场景:
  • 一笔订单,可能是微信支付、也可能是支付宝支付的
  • 这时候订单表 order 可以增加两个字段: payment_id、payment_type,这时候用多态关联 $order->payment 可以很方便的关联到这笔订单对应的支付记录
3年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!