【问题标题】:Nested hasManyThrough performance嵌套 hasManyThrough 性能
【发布时间】:2021-04-21 20:34:52
【问题描述】:

我的数据库布局出现问题。基本上,布局以以下方式呈现:

- Community
- - Each community has officers (Model `User`)
- - Each community has participants (Model `User`)

- Chat rooms (different section)
- - each chat room has participants (Model `User`)
- - each chat has officers, which are generated based on the participant's community's officers. This means: It's not hard-coded into a new table, instead, it should fetch the officers of the community, to which the participant (non-officer) belongs to.

我的奋斗目标是实现最后一部分,即“官员可以访问”。我现在的查询完全是一团糟,尤其是当前服务器的计划。考虑到代码很长,我会直截了当:

- Fetch chat rooms
- - fetch participants of each chat room
- - - fetch communities of each participant 
- - - - fetch officers of each community 
- - - - add these officers to a main array in the model
- - - - remove any duplicated officers 

现在,您可以看到这是一种非常松散的获取结果的方式,并且会消耗大量性能。官员和非官员之间唯一相关的模型是community

最好的方法是什么?

【问题讨论】:

  • 了解JOIN
  • 我确实考虑过这一点,但我认为使用 Eloquent 模型是“最佳实践”?我应该只在关系中进行原始查询吗?

标签: mysql laravel eloquent


【解决方案1】:

您对创建新表chat_room_community 有何看法,您将在其中存储社区聊天室。 该表将包含 community_iduser_idchat_room_id 列。 每次用户加入/离开聊天室时,在此表中添加/删除记录。 每当用户加入新社区或离开社区时,您还必须修改此新表,但通过这种方法,您可以通过简单的查询 (SELECT * FROM chat_room_community where community_id = ?)

获得所有可用的官员聊天室

【讨论】:

  • 我实际上想到了这一点,但是我需要更新两个表。添加/删除人员时community_officers的表和新的chat_room_community表。这对于雄辩的标准来说不是多余的吗?
猜你喜欢
  • 2021-12-27
  • 1970-01-01
  • 2015-02-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-11-15
相关资源
最近更新 更多