我想显示特定城市的最后四个星期日温度，我需要每周更新数据库（星期日）
city_id temp_pre_sunday1 temp_pre_sunday2 temp_pre_sunday3 temp_pre_sunday4
1 24.3 35.2 24.4 28.0
2 4.0 2.0 6.0 7.0
.
2000
我可以在每个星期天更新数据库。这是一个很好的数据库设计吗？
city_id temp date
1 24.3 2017-12-03
1 35.2 2017-11-26
1 24.4 2017-11-19
1 28.0 2017-11-12
2 4.0 2017-12-03
2 2.0 2017-11-26
2 6.0 2017-11-19
2 7.0 2017-11-12
.
.
我只需要四个星期日，而不是更多。
我认为第一种方法更好，因为这种方式对于2000个城市我将有2000行和5列，在第二种方法我将有8000行和3列，
但是在第一种方法中，我需要更新所有四列，但在第二种方法中，我可以删除并插入一行。
哪种数据库设计更好？
答案 0 :(得分：1)
数据库设计2是最好的方法。您可以更好地控制和灵活地操作数据，生成报告和扩展应用程序等......
说，如果你想获取5周或更长时间而不是4周的数据怎么办？对于数据库设计2，您只需要修改查询：
SELECT city_id, temp FROM table WHERE date >= _last_n_week_sunday_date_
另一件事是，我可能认为你正在创建一个天气应用程序，并试图获取每个城市的月平均温度，更简单的查询可以得到报告
SELECT city_id, YEAR(date), MONTH(date), AVG(temp) FROM table GROUP BY city_id, YEAR(date), MONTH(date)
湿度说，你可能还希望在每个城市的后期存储更多属性。您只需要为数据库设计创建1个列2.相反，您可能需要做更多努力才能使用数据库设计1.
答案 1 :(得分：1)
评估＆＃34;最好的方式＆＃34;很复杂。但是＆＃34;行数＆＃34;在关系数据库中几乎从不存在问题 - 它们专门用于处理大量行。
考虑它的一个更有用的方法是＆＃34;我想用数据做什么常见的事情＆＃34;。
我猜你有几个用例。
第一个是＆＃34;记录新的测量值＆＃34;。正如你所说，这在设计上有点痛苦。
第二个是＆＃34;查找或报告测量结果＆＃34;。
在设计一中，很容易回答诸如＆＃34;上周日x市的温度是多少？＆＃34;。但是＆＃34;过去3周内最冷的温度是多少？＃34;更难。或者＆＃34; X市的最高温度和最低温度之间有什么区别？＆＃34;。如果将周数作为参数传入，则最终会构建尴尬的查询。在设计二中，所有这些查询都非常简单。
仅此一点表明设计2更好。
但是，正如评论者所指出的那样，对数据库的要求往往会发生变化。如果您可以通过添加数据来适应这些更改，而不是更改架构，那么大多数人都认为您有一个好的设计。因此，如果您需要存储超过4个星期日的数据，设计2需要更改架构;设计1没有。如果你必须记录温度以外的数据，在设计1中你突然每周有多列;在设计2中，您只需添加一个＆＃34; measurement_type＆＃34;专栏（一个小得多的变化）。因此，面对变化，设计2可能更灵活。