我有一个表“user_plays_track”,用于跟踪用户“播放”轨道的次数。
我使用以下查询来插入用户播放过的新轨道,或更新现有轨道的播放次数:
INSERT INTO user_plays_track
(user_id, track_id) VALUES (x,y)
ON duplicate key UPDATE play_count = play_count+1
这是我的表的结构:
user_id track_id play_count
1 5 2
4 2 1
3 5 7
根据这些信息,我可以通过查找所有轨道计数的总和来推断诸如轨道已播放的总次数或艺术家已播放的总次数之类的信息。
如果有一千左右的记录,这很快就会变得困惑,语义也不清楚。我想做的是使用触发器来生成可以描述为缓存的内容。
例如,当更新或插入一条记录到“user_plays_track”时,“tracks”表将增加其 play_count 列,指示所有用户对该轨道的播放总数。
track_id artist_id track_name play_count
2 1 Hey 1
5 1 Test 9
更进一步,应该应用另一个触发器来推断新的知识,例如艺术家戏剧的总数。当添加新轨道时,这将再次触发,它将找到该轨道所属的artist_id并相应地更新“artist”表。
artist_id artist_name play_count
1 Bob 10
我将如何实现相关触发器,以便在用户“播放”轨道时提供递增的总数?
最佳答案
您希望在查询时计算的内容越多,您就越需要 View 、计算列以及存储例程或用户例程。您想要在标准化基础更新时间计算的越多,您就越需要级联和触发器。您想要在其他(计划的或临时的)时间计算的越多,您使用快照(又名物化 View )和更新的非规范化基础的次数就越多。您可以将这些结合起来。任何时候访问数据库都可以通过存储例程或其他 API 来启用和限制。
在您能够证明它们足够之前, View 和计算列是最简单的。
DBMS 的整体思想是将应用程序状态的表示存储为数据库(规范化减少了冗余),然后查询并让 DBMS 实现并优化答案的计算。您没有给出不以最直接的方式这样做的理由。关于mysql - 使用更新和插入触发器在其他关系中提供计数列,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24193410/