设计数据库结构时需要把前端需要的数据存入数据库吗？

那要先考虑一个场景。

有没有比如查这个星期的最低价？最近 10 天的最低价？ 最近季度的最低价？

还是说单纯的固定查询 比如全历史最低价 和 每日最低价？

这么说你不纠结了吧。。

ps.不要相信产品说的话。

@MangozZ 谢谢，您的建议是只记录最基本的数据值，其他能通过计算得出的都不记录是吗，
我其实很想知道专业的程序员们在设计数据库结构时候是怎么规划的，普遍是 1 还是 2，或者分情况 1、2 都有

@cingular 操作数据库的开销比较大，数据表更是不适合朝令夕改，所以一般只存一些比较固定的数据。
那些需要计算的临时数据，如果有性能瓶颈，可以做缓存。极少会有需要存到数据库的情况。

直接 SELECT MIN(price)不行吗

@cingular 设计的时候 还是按照 2.随时计算 来设计。 因为筛选范围不固定，不可能记录的下各种情况。

如果有我所说的固定查询，全历史最低价 和 每日最低价 等非常容易命中的范围， 则放在另一张的新建表。 以后可以随时抛弃该冗余表。

ps.放我 mysql 一马吧。

1. 本着尽可能精简的原则设计，也就是能不存就不存。
2. 根据产品需求、运营需要、商务策略、客户要求、技术复杂度等各种因素，综合评估确认需要冗余，再冗余。并且此时依然要考虑 1 里的描述。在效率和复杂度上把握平衡。

有些情况冗余字段的效果很好，有些则没多大意义。

例如简单的数学计算，递增递减，在每次数据变化时提前计算好结果放到冗余字段里，就比取出来一个再一个个算要合算。当然，也可以不冗余字段，客户端或前端显示时计算。但这样又会把业务逻辑放到前台，带来更新上的效率问题。

又例如每次计算冗余结果时，本身就要对数据库进行查询，当数据稍微多一些或关联多一些，性能就会急速下降，这种就不合适冗余字段来处理，可以上缓存。如果确定冗余时查询的内容复杂度不会变多，比如固定 200 条或 300 条，更改架构添加缓存较为复杂，那又可以冗余字段来处理。

总之，这是很依赖实际情况的，项目不同，技术选型不同，人也不同，做的选择和倾向性也会不同。
个人观点，供参考。

@cingular #2

明白了，感谢各位！

前端页面改版难不成你也要跟着改???

1，2 情况都有，1 情况相当于缓存，特别是改动不大、统计比较费时费资源情况下，选 1。你举得这个例子完全没必要去存，实时计算很方便。