处理动态旋转数据的应用程序设计

Question

对于每种记录类型，我有一个具有不同粒度的应用程序。假设库存类型A是按季度计划的，所以它有4个值，而库存类型B是按月计划的，所以它有12个值。假设月是最低的时间范围，因此表的最大值为12。从UI的角度来看，UI需要以旋转的方式显示记录。意思是说如果系统正在显示库存类型A，它将显示类似于

Inventory Type | Time       | Value 1 | Value 2 | Value 3 | Value 4
A              | Quarterly  | 100     | 200     | 300     | 400

在这里，值1表示Q1的值，值2表示Q2的值，依此类推。

当它显示库存类型B时，它将显示类似于

Inventory Type | Time      | Value 1 | Value 2 | Value 3 | Value 4 | Value 5 | Value 6 | Value 7 | Value 8 | Value 9 | Value 10 | Value 11 | Value 12
B              | Monthly   | 1       | 2       | 3       | 4       | 5       | 6       | 7       | 8       | 9       | 10       | 11       | 12

这里的值1代表一月的值，2表示二月的值，依此类推。

用户可以去编辑UI上的值并保存回数据库。

我在考虑两个设计之间的数据库。

设计1

创建父-子表：

Parent table

ID | Inventory Type | Time
1  | A              | Quarterly
2  | B              | Monthly

Child table

Child ID | Parent ID | Value Name    | Value
1        | 1         | Value 1       | 100
2        | 1         | Value 2       | 200
3        | 1         | Value 3       | 300
4        | 1         | Value 4       | 400
5        | 2         | Value 1       | 1 
6        | 2         | Value 2       | 2
7        | 2         | Value 3       | 3
8        | 2         | Value 4       | 4
9        | 2         | Value 5       | 5
10       | 2         | Value 6       | 6
11       | 2         | Value 7       | 7
12       | 2         | Value 8       | 8
13       | 2         | Value 9       | 9
14       | 2         | Value 10      | 10
15       | 2         | Value 11      | 11
16       | 2         | Value 12      | 12

使用这种方法，在读取数据时，我需要进行一些旋转，以便它可以显示在UI上。类似地，在保存数据时，我需要卸载数据，并相应地创建/更新子记录。因此，在后端进行转换的过程有点重，但存储效率更高。

设计2

假定最大值为12，则只创建一个表。

ID | Inventory Type | Time        | Value 1 | Value 2 | Value 3 | Value 4 | Value 5 | Value 6 | Value 7 | Value 8 | Value 9 | Value 10 | Value 11 | Value 12
1  | A              | Quarterly   | 100     | 200     | 300     | 400     | NULL    | NULL    | NULL    | NULL    | NULL    | NULL     | NULL     | NULL    
2  | B              | Monthly     | 1       | 2       | 3       | 4       | 5       | 6       | 7       | 8       | 9       | 10       | 11       | 12      

读取和保存数据非常简单，不需要支点和非枢轴，但是存储效率不高(查看库存类型A，值从5到12总是为空)。由于处理较少，性能应该更快。

解决这个问题的更好方法是哪一种？

Answer 1

“更好”取决于许多因素。因为你没有把它们全部列出来，所以不可能知道哪一个更好。您已经列出了一些优点和缺点(尽管存储参数可能没有意义，因为大多数数据库都有非常有效的方法来处理空列)。

您应该关注这个数据模型的语义，而不是关注一些可能不相关的优化。这些属性代表什么？你能给他们起有意义的名字吗？为什么两个记录类型都存储在同一个表中？它们的共同点和(或)差异是什么？如果您的数据模型正确，您可能会更好地理解如何最好地实现它。也许有两张不同的桌子是最简单的？也许仅仅拥有空值并不优雅，但却提供了最好的性能？也许是一个单独的表，用于B类型的记录，它只保存属性3和4的值(尽管这不太可能提供比空列更好的行为)？