MySql：使用“视图”是否合理,或者我最好对数据库进行非规范化？

有一个带有以下字段的“ team_sector”表：Id,team_id,sect_id,大小,级别

它包含每个“团队”实体的很少记录(用“ team_id”字段引用).每个记录代表团队运动场的扇区(总共8个扇区).

现在有必要执行一些搜索：

>按体育场总体规模(SUM(size))；
>最佳质量(SUM(级别)/ COUNT(*)).

我可以创建如下查询：

SELECT TS.team_id, SUM(TS.size) as OverallSize, SUM(TS.Level)/COUNT(TS.Id) AS QualityLevel
FROM team_sector
GROUP BY team_id
ORDER BY OverallSize DESC / ORDER BY QualityLevel DESC

但是我在这里担心的是,每次执行查询时,都会对每个团队进行计算.它的开销不是太大(至少现在是这样),但我想避免以后出现性能问题.

我在这里看到2个选项.

第一个是在“团队”表中创建2个其他字段(例如),并在其中存储TotalSize和QualityLevel字段.如果有关“扇区”表的信息已更改,请也更新这些表(使用触发器进行此操作可能会很好,因为扇区表不会经常更改).

第二个选项是创建一个将提供所需数据的视图.

第二个选项对我来说似乎容易得多,但是我对视图的工作经验不足.

问题1：从您的角度来看,最佳选择是什么？为什么？也许您可以建议其他选择？

问题2：是否可以以很少进行计算(每天至少一次)的方式创建视图？如果是,怎么办？

问题3：为此目的使用触发器是否合理(第一种选择).

附言使用MySql 5.1,团队总数在1-2千左右,扇区表中记录的总数-总数在6-8千.我知道,这些数字很小,但是我想在这里实施最佳做法.

解决方法:

数以万计的记录是您不应该担心的.

最佳做法是

>以规范化的方式存储数据,并让数据库引擎处理计算
>正确索引数据,不时进行索引维护
>避免使用“父”记录存储汇总值
>在应用程序层中进行一些结果缓存,以避免不必要地频繁访问数据库服务器
>处理性能问题

是的,无论何时执行视图/查询,数据库都会计算SUM(),但是对于您所描述的场景,我希望结果会很快.

如果遇到一个非常复杂的视图,需要很长时间来计算,并且找不到任何进一步优化表的方法,则可以引入一个帮助器表,该表定期(或通过触发器)填充视图结果,并进行查询该表而不是慢速视图.

恕我直言,预见可能的性能瓶颈并在它们真正出现之前“关闭”它们会浪费您的时间.

标签：mysql5,view,mysql
来源： https://codeday.me/bug/20191208/2094597.html