我有一堆函数，它们有很多输入参数，但输入参数相对较少，我试图将输出列表，以便我可以查看输入。通常，我将为给定的函数提供一组2D表，其中一些规则决定了要查看的表。因此，例如，如果某个变量的值小于1，我应该查看表1，但如果变量大于或等于1，我应该查看表2以确定输出（但更通常是表格到使用将取决于5或6个变量的值）。还有一个问题 - 表2和表1不一定具有相同的行和列。列。
到目前为止，我的解决方案是创建包含所有表的所有信息的平面文件表（所以我最终得到一个大的复杂表），表中的值表示在一个单独的列中表的结尾（输入在此之前的所有列中表示）。因为并非所有表都相同，这意味着我有很多零或空格（表不适用）。这个解决方案适用于我的目的，但是当我尝试将更多功能列表时，表变得越来越复杂，并且有人能够轻松地检查和验证表值是非常重要的。我希望有一种更清晰的方式来使用关系数据库来呈现信息，但我不确定这是否会使事情变得更加清晰。使用我的分类平面文件到目前为止已经相当清楚，但随着表格变得越来越复杂，人们阅读越来越困难，并且问题开始出现。
我已经研究过数据库设计原则，但我发现的所有介绍材料都使用了比我简单得多的例子，而且我不确定如何扩展我所阅读的内容以满足我的需要。我的理解是，如果我的函数有N个输入，那么我需要N + 1个表来创建一个关系数据库;所以我不确定这是否会使事情变得更清楚或更清晰。我希望这是数据库专家的常见问题，有人会有一些建议！
修改
已经请了一个例子，所以我做了一个与我的问题类似的问题。假设我想弄清楚在给定日期服装的价格是多少。我有三个2D表格可以提供这些信息：
2010年1月1日之前：
+--------+----------+----------+----------+----------+
| | Fabric A | Fabric B | Fabric C | Fabric D |
+--------+----------+----------+----------+----------+
| Size S | 1 | 2 | 3 | 4 |
| Size M | 5 | 6 | 7 | 8 |
| Size L | 9 | 10 | 11 | 12 |
+--------+----------+----------+----------+----------+
2010年1月1日之后：
如果Designer是P：
+--------+------------+------------+------------+
| | Location X | Location Y | Location Z |
+--------+------------+------------+------------+
| Size S | 1 | 2 | 3 |
| Size M | 5 | 6 | 7 |
| Size L | 9 | 10 | 11 |
+--------+------------+------------+------------+
如果Designer是Q：
+--------+------------+------------+------------+
| | Location X | Location Y | Location Z |
+--------+------------+------------+------------+
| Size S | 2 | 2 | 3 |
| Size M | 4 | 5 | 5 |
| Size L | 6 | 7 | 8 |
+--------+------------+------------+------------+
这就是三张桌子。我所做的就是创建一个像这样的表：
+------------+----------+------+--------+----------+-------+
| Date | Designer | Size | Fabric | Location | Price |
+------------+----------+------+--------+----------+-------+
| 01/01/2010 | P | L | A | X | 6 |
| 01/01/2010 | P | L | A | Y | 7 |
| 01/01/2010 | P | L | A | Z | 8 |
| 01/01/2010 | P | L | B | X | 6 |
| 01/01/2010 | P | L | B | Y | 7 |
| 01/01/2010 | P | L | B | Z | 8 |
| 01/01/2010 | P | L | C | X | 6 |
| 01/01/2010 | P | L | C | Y | 7 |
| 01/01/2010 | P | L | C | Z | 8 |
| 01/01/2010 | P | L | D | X | 6 |
| 01/01/2010 | P | L | D | Y | 7 |
| 01/01/2010 | P | L | D | Z | 8 |
| 01/01/2010 | P | M | A | X | 4 |
| 01/01/2010 | P | M | A | Y | 5 |
| 01/01/2010 | P | M | A | Z | 5 |
| 01/01/2010 | P | M | B | X | 4 |
| 01/01/2010 | P | M | B | Y | 5 |
| 01/01/2010 | P | M | B | Z | 5 |
| 01/01/2010 | P | M | C | X | 4 |
| 01/01/2010 | P | M | C | Y | 5 |
| 01/01/2010 | P | M | C | Z | 5 |
| 01/01/2010 | P | M | D | X | 4 |
| 01/01/2010 | P | M | D | Y | 5 |
| 01/01/2010 | P | M | D | Z | 5 |
| 01/01/2010 | P | S | A | X | 2 |
| 01/01/2010 | P | S | A | Y | 2 |
| 01/01/2010 | P | S | A | Z | 3 |
| 01/01/2010 | P | S | B | X | 2 |
| 01/01/2010 | P | S | B | Y | 2 |
| 01/01/2010 | P | S | B | Z | 3 |
| 01/01/2010 | P | S | C | X | 2 |
| 01/01/2010 | P | S | C | Y | 2 |
| 01/01/2010 | P | S | C | Z | 3 |
| 01/01/2010 | P | S | D | X | 2 |
| 01/01/2010 | P | S | D | Y | 2 |
| 01/01/2010 | P | S | D | Z | 3 |
| 01/01/2010 | Q | L | A | X | 9 |
| 01/01/2010 | Q | L | A | Y | 10 |
| 01/01/2010 | Q | L | A | Z | 11 |
| 01/01/2010 | Q | L | B | X | 9 |
| 01/01/2010 | Q | L | B | Y | 10 |
| 01/01/2010 | Q | L | B | Z | 11 |
| 01/01/2010 | Q | L | C | X | 9 |
| 01/01/2010 | Q | L | C | Y | 10 |
| 01/01/2010 | Q | L | C | Z | 11 |
| 01/01/2010 | Q | L | D | X | 9 |
| 01/01/2010 | Q | L | D | Y | 10 |
| 01/01/2010 | Q | L | D | Z | 11 |
| 01/01/2010 | Q | M | A | X | 5 |
| 01/01/2010 | Q | M | A | Y | 6 |
| 01/01/2010 | Q | M | A | Z | 7 |
| 01/01/2010 | Q | M | B | X | 5 |
| 01/01/2010 | Q | M | B | Y | 6 |
| 01/01/2010 | Q | M | B | Z | 7 |
| 01/01/2010 | Q | M | C | X | 5 |
| 01/01/2010 | Q | M | C | Y | 6 |
| 01/01/2010 | Q | M | C | Z | 7 |
| 01/01/2010 | Q | M | D | X | 5 |
| 01/01/2010 | Q | M | D | Y | 6 |
| 01/01/2010 | Q | M | D | Z | 7 |
| 01/01/2010 | Q | S | A | X | 1 |
| 01/01/2010 | Q | S | A | Y | 2 |
| 01/01/2010 | Q | S | A | Z | 3 |
| 01/01/2010 | Q | S | B | X | 1 |
| 01/01/2010 | Q | S | B | Y | 2 |
| 01/01/2010 | Q | S | B | Z | 3 |
| 01/01/2010 | Q | S | C | X | 1 |
| 01/01/2010 | Q | S | C | Y | 2 |
| 01/01/2010 | Q | S | C | Z | 3 |
| 01/01/2010 | Q | S | D | X | 1 |
| 01/01/2010 | Q | S | D | Y | 2 |
| 01/01/2010 | Q | S | D | Z | 3 |
| 01/01/1900 | P | L | A | X | 9 |
| 01/01/1900 | P | L | A | Y | 9 |
| 01/01/1900 | P | L | A | Z | 9 |
| 01/01/1900 | P | L | B | X | 10 |
| 01/01/1900 | P | L | B | Y | 10 |
| 01/01/1900 | P | L | B | Z | 10 |
| 01/01/1900 | P | L | C | X | 11 |
| 01/01/1900 | P | L | C | Y | 11 |
| 01/01/1900 | P | L | C | Z | 11 |
| 01/01/1900 | P | L | D | X | 12 |
| 01/01/1900 | P | L | D | Y | 12 |
| 01/01/1900 | P | L | D | Z | 12 |
| 01/01/1900 | P | M | A | X | 5 |
| 01/01/1900 | P | M | A | Y | 5 |
| 01/01/1900 | P | M | A | Z | 5 |
| 01/01/1900 | P | M | B | X | 6 |
| 01/01/1900 | P | M | B | Y | 6 |
| 01/01/1900 | P | M | B | Z | 6 |
| 01/01/1900 | P | M | C | X | 7 |
| 01/01/1900 | P | M | C | Y | 7 |
| 01/01/1900 | P | M | C | Z | 7 |
| 01/01/1900 | P | M | D | X | 8 |
| 01/01/1900 | P | M | D | Y | 8 |
| 01/01/1900 | P | M | D | Z | 8 |
| 01/01/1900 | P | S | A | X | 1 |
| 01/01/1900 | P | S | A | Y | 1 |
| 01/01/1900 | P | S | A | Z | 1 |
| 01/01/1900 | P | S | B | X | 2 |
| 01/01/1900 | P | S | B | Y | 2 |
| 01/01/1900 | P | S | B | Z | 2 |
| 01/01/1900 | P | S | C | X | 3 |
| 01/01/1900 | P | S | C | Y | 3 |
| 01/01/1900 | P | S | C | Z | 3 |
| 01/01/1900 | P | S | D | X | 4 |
| 01/01/1900 | P | S | D | Y | 4 |
| 01/01/1900 | P | S | D | Z | 4 |
| 01/01/1900 | Q | L | A | X | 9 |
| 01/01/1900 | Q | L | A | Y | 9 |
| 01/01/1900 | Q | L | A | Z | 9 |
| 01/01/1900 | Q | L | B | X | 10 |
| 01/01/1900 | Q | L | B | Y | 10 |
| 01/01/1900 | Q | L | B | Z | 10 |
| 01/01/1900 | Q | L | C | X | 11 |
| 01/01/1900 | Q | L | C | Y | 11 |
| 01/01/1900 | Q | L | C | Z | 11 |
| 01/01/1900 | Q | L | D | X | 12 |
| 01/01/1900 | Q | L | D | Y | 12 |
| 01/01/1900 | Q | L | D | Z | 12 |
| 01/01/1900 | Q | M | A | X | 5 |
| 01/01/1900 | Q | M | A | Y | 5 |
| 01/01/1900 | Q | M | A | Z | 5 |
| 01/01/1900 | Q | M | B | X | 6 |
| 01/01/1900 | Q | M | B | Y | 6 |
| 01/01/1900 | Q | M | B | Z | 6 |
| 01/01/1900 | Q | M | C | X | 7 |
| 01/01/1900 | Q | M | C | Y | 7 |
| 01/01/1900 | Q | M | C | Z | 7 |
| 01/01/1900 | Q | M | D | X | 8 |
| 01/01/1900 | Q | M | D | Y | 8 |
| 01/01/1900 | Q | M | D | Z | 8 |
| 01/01/1900 | Q | S | A | X | 1 |
| 01/01/1900 | Q | S | A | Y | 1 |
| 01/01/1900 | Q | S | A | Z | 1 |
| 01/01/1900 | Q | S | B | X | 2 |
| 01/01/1900 | Q | S | B | Y | 2 |
| 01/01/1900 | Q | S | B | Z | 2 |
| 01/01/1900 | Q | S | C | X | 3 |
| 01/01/1900 | Q | S | C | Y | 3 |
| 01/01/1900 | Q | S | C | Z | 3 |
| 01/01/1900 | Q | S | D | X | 4 |
| 01/01/1900 | Q | S | D | Y | 4 |
| 01/01/1900 | Q | S | D | Z | 4 |
+------------+----------+------+--------+----------+-------+
我无法将小桌子用于我的目的（我不会想到），但我可以很容易地使用大桌子。但是，这引入了次要要求：其他人现在需要能够定期检查大表是否完全包含来自小表的所有信息。对于某人来说，检查大表中的给定价格是否与适当的小表中的价格一致并不难，但随着我们添加更多表格并涉及更多参数，很难发现其他问题（例如，缺少条目）。需要回答的问题是＆＃34;大桌子可以用来正确查找一件衣服的所有可能价格吗？＆＃34;。
我目前的想法是，我想设置一个非常容易检查的小表，并且可能会自动生成大表的过程，以便对流程的信心=＆gt;对大桌子的信心。我也想知道是否需要大表来进行我希望能够进行的查找，或者是否有一种聪明的方法可以直接从小表中获取输出（使用聪明的数据库设计，也许？）。
也许这只是一个难题，但我想知道是否有一个明显优于其他解决方案的解决方案。
编辑：
感谢所有评论到目前为止。不幸的是，我很难理解一些答案，似乎问题仍然太模糊，无法正确回答。我只是试着在已经给出的例子的背景下充实我的问题。
在我上面的服装示例中，我说一般服装的价格是销售日期，销售地点，设计师，尺码，面料的函数。我创建了一个表来表达这些输入和价格之间的关系。
但是，此表中的许多行不会从所有列中受益 - 例如，对于在2010年1月1日之前销售的任何内容，都不会依赖于设计器。为了在我的大表中对其进行编码，我必须添加许多额外的行，以确保在2010年1月1日之前售出的任何内容为设计者P提供与任何其他输入组合相同的答案。这似乎效率低下，但我不确定如何（或是否）更好地制定这一点。我试图理解标准化的过程，但我很难看到这对于这个服装的例子是如何起作用的 - 而且，我还不确定标准化是否会使表更加清晰（因为这是我现在的主要目标）。
作为额外的业务限制，我可以随时收到有关价格或新定价方法的更多信息。所以完全可以想象我可能需要在我的大表中添加几个输入（列），并且整个加载更多行以捕获现在价格如何依赖于每个输入，即使这只会导致一个或多个两个截然不同的新价位。在我的例子中，我有三个小桌子，但实际上我将有数百个。这有很多信息，并且没有办法解决这个问题，但我确信有一种方法可以做到这一点，不需要数百个小表或数千个基本上大表中的冗余行。我正在努力想知道如何将其分解。是否有一种方法可以将其分解，这对人眼来说更清晰？有没有办法制定它意味着当新输入出现时，我不必在我的表中添加1000个冗余行？标准化是我需要做的吗？
我还没有完全理解已经给出的答案和资源，所以我会继续尝试消化这些，但希望这个编辑可以解决我所问的一些模棱两可的问题。
答案 0 :(得分：0)
TL; DR 您的文字表是关系图片＆amp;功能。您需要忘记格式化和“2D”和“平面”，并根据表所代表的应用关系确定其值相关的维度。如果要以某种格式显示关系，那就是用户图形界面问题。
您需要阅读并了解关系模型，信息建模和规范化。
使用关系数据库时，规范图片（但只是图片）是将应用程序关系的所有维度放在顶部。
价格是尺寸尺寸的价格，面料 Fabric 2010年1月1日后由P
设计+------+--------+-------+
| Size | Fabric | Price |
+------+--------+-------+
| S | A | 1 |
| S | B | 2 |
...
| L | D | 12 |
+------+--------+-------+
但是等等！上表是某些表的一部分，如：
价格是在 Designer <设计之后 的尺寸的价格 / em> AND After = 1/1/2010 AND Designer = P
+------+--------+------+----------+----------+
| Size | Fabric | Price| Designer | After |
+------+--------+------+----------+----------+
| S | A | 1 | P | 1/1/2010 |
| S | A | 1 | P | 1/1/2010 |
...
| L | D | 12 | P | 1/1/2010 |
+------+--------+------+----------+----------+
这是某些表的一部分，如：
价格是在 Designer <设计之后 的尺寸的价格 / em>的
+------+--------+-------+----------+----------+
| Size | Fabric | Price | Designer | After |
+------+--------+-------+----------+----------+
| S | A | 1 | P | 1/1/2010 |
...
| M | D | 8 | Q | 1/1/1900 |
...
+------+--------+-------+----------+----------+
另一方面，如果该表的标签总是表示“价格是尺寸尺寸的价格，其中 Fabric 和 Price 是由 Designer 设计的 After 后的价格，而其他一些事情则是如此，那么我们只需要第一张表和这一张：
价格是 Designer 设计的之后之后的价格
+-------+----------+----------+
| Price | Designer | After |
+-------+----------+----------+
| 1 | P | 1/1/2010 |
...
| 8 | Q | 1/1/1900 |
...
+-------+----------+----------+
因为能够从较小的那个重建较大的那个。
关系将包含有关业务情境的谓词 aka参数化语句的行保存为真实语句。两个关系的join包含使其谓词的“AND”成为真实语句的行。 （并且union“或”等等。）数据库设计是关于找到描述任何业务情况的必要和充分的谓词。我们根据那些基本谓词/表描述我们希望作为查询的谓词/表。我们尝试简化谓词/表格。我们试图最大限度地减少谓词/表格的可表达性（全部或部分）。我们可以在输出上以各种方式格式化。我们还确定了描述有效数据库状态的约束（相当于可能出现的应用程序情况），因此DBMS可以拒绝无效的更新尝试。
在设计时，一旦我们有一些完整描述我们业务情况的谓词/表，我们就会通过基于 normalization 的 normalization 使谓词/表更小且独立。 em>功能依赖和加入依赖。信息建模方法通常会尝试生成已经至少在某种程度上标准化的基本谓词/表。
功能依赖性涉及谓词/表，其中列是其他列的功能。连接依赖项涉及使用“AND”的谓词/表。 （每个函数依赖都带有一个连接依赖。）规范化涉及用较小的替换谓词/表来摆脱有问题的功能和连接依赖。
答案 1 :(得分：0)
作为额外的业务限制，我可以随时收到有关价格或新定价方法的更多信息。所以完全可以想象我可能需要在我的大表中添加几个输入（列），并且整个加载更多行以捕获现在价格如何依赖于每个输入，即使这只会导致一个或多个两个截然不同的新价位。在我的例子中，我有三个小桌子，但实际上我将有数百个
我认为这是一个红旗，告诉你一个纯粹的关系存储机制对你来说不会很好。
说实话，我不确定适当的机制是什么，但似乎您需要能够将产品和日期传递给函数，然后使用业务规则来确定合适的价格，因此，我认为你需要像商业规则引擎这样的东西。