Database DB设计：域对象是固定列、固定行的表，如何为它设计DB表？

设计我当前的应用程序我遇到了一个问题：用户提供了以下要求：

对于每个企业（假设有一个企业表，企业id作为键），都有一个固定的数据集，其结构大致如下：

             | Income | Declared | Expenses | Normalized | Whatever | etc
-------------+--------+----------+----------+------------+----------+-...
Short term   |
Medium term  |
Long term    |
Unspecified  |
Unknown      |

term          category    term_category_value
--            --          --
Short term    Income      <some currency amount>
Short term    Declared    <some currency amount>
...
Short term    Whatever    <some currency amount>
Middle term   Income      <some currency amount>
Middle term   Declared    <some currency amount>
...    

关键的一点是（概念上）列是固定的，行是固定的。所谓固定，我的意思是这是我国的成文法！所以短期内不会改变

我的疑问是：“user”表的每个实例（具有固定的M列和N行）在我看来都像一个DB行（与enterprise_id有1:1的对应关系，所有数据每次都将作为单个块保存/检索，等等）。另一方面，这是很多列（在我的真实应用程序中，MxN可能有100个），坦白地说，它看起来很难看，所以我对此感到不安

因此，我应该为这个用户数据创建一个表，其中包含（MxN）列（加上一个enterprise_id外键），还是应该创建两个表，一个包含可能的“用户”行（“短期”，等等），另一个仅包含列（“收入”，等等），在这种情况下，每一行都是（企业id、可能的行id、收入、申报收入等）

---

提前感谢！

假设这些值都是某种货币，我的第一个想法是您可能需要这样一个表：

             | Income | Declared | Expenses | Normalized | Whatever | etc
-------------+--------+----------+----------+------------+----------+-...
Short term   |
Medium term  |
Long term    |
Unspecified  |
Unknown      |

term          category    term_category_value
--            --          --
Short term    Income      <some currency amount>
Short term    Declared    <some currency amount>
...
Short term    Whatever    <some currency amount>
Middle term   Income      <some currency amount>
Middle term   Declared    <some currency amount>
...    

术语类别术语类别值
--            --          --
短期收入
短期申报
...
短期的
中期收入
宣布中期选举
...    

---

根据您的dbms，使此类数据看起来像电子表格可能相当简单，也可能有点困难。但您只需构建一个视图即可完成此操作。例如，SQL Server有PIVOT。其他一些平台称之为CROSSTAB。

如果Enterprise中的列为1:：1，则它们应该位于Enterprise中。但在某个时候，您会遇到r最大长度

---

因此，使用第二个表，将MxN列和EnterpriseId同时用作PK和FK。

Yep，这是另一种可能性：“用户”中的每个单元格表是DB表中的一行。这是我考虑过的第二个选项，但使用了两个维度而不是一个维度。不幸的是，并非所有列都是通用的，而且，无论如何，我认为我也不喜欢它，因为我觉得这个解决方案在不需要它的地方增加了自由度（所有字段都是必需的，但这种设计无法强制执行）。谢谢！事实上，如果您的dbms允许在检查约束中使用用户定义的函数，那么您可以强制执行相当任意的检查约束。但是不同的数据类型在很大程度上阻碍了这种方法的实施。“…按照创建两个表的思路”你会在哪些列上加入这两个表？如果立法者要求你进行数据库设计，那你就不走运了。如果你能侥幸逃脱，在不模仿法律细节的情况下遵守法律的意图。在任何合理的世界里，如果你能在屏幕上或摘录中重新创建法律要求的格式，你就在法律的意图之内。