Database DB应用程序设计。易于扩展

我觉得这是一个有点“愚蠢”的问题，但不管怎样，还是这样吧，因为它可能对其他人有用。 而且它有点长，因为我想给我的情况的背景

背景：
我正在开发一个db应用程序，使我们能够“跟踪”各种项目的费用。我确信已经有一个应用程序可以做到这一点，但我仅限于使用VBA，所以MS Access。 有人告诉我，他们不想学习“新”的东西，我相信任何其他“新”产品都需要大量的“调整”，以提供我们需要的所有“补充”功能和细节

问题：
这些可能是围绕我的基本问题的连锁反应，欢迎您的想法，如果它可能导致一个有趣的讨论，我很高兴把每一个小问题都变成一个新问题，但我在这里包括这些内容以供完成

我有多个表，它们在“路径”中相互链接 因此，每个表都存储信息。为了简单起见，让我们将其视为 项目：地点（地理）：参观人员 （事实上，这条路径中还有另外4个表，但是…） 由于每个位置可以存在于每个项目中，因此我有一个“project_2_location”表，将这些表链接在一起 以及每个中间表和其他中间表之间的另一个“链接”表。 因此，如果表是A、B、C和D，则链接表是 A_2_B:B_2_C:C_2_D:等等。。。（我不做A_2_C和A_2_D）

我还有大量的2列“lookup”表（事实上，我的“lookup”类型表比我的“true”表多，这在“设计视图”中显示了我）

我的主要问题。 我还有另外一套表格，它们让我对如何最好地继续下去感到有些“悲伤”。正是这些是我“问题”的根源

我有两个表在一对多关系SIP中链接，我在父表中使用一个“single”值链接到子表（子表有自己的代理键）

显然，他们对“child”表中的细节并不特别感兴趣，但我创建了它，因为它是使接口工作并维护某种“第一范式”的最方便的方式

现在我已经创建了这个子表，我知道他们将来会想对它运行查询（即使现在他们说他们不想）。要做到这一点，他们将“必须”在父表、父表和父表之间创建一个连接，以提取他们需要的所有信息

简而言之，我有

Granparent（用作项目名称的查找表）

Parent（具有祖父母PK的外键，是“oneGranparent”到“ManyParent”类型的关系）

子级（具有父级PK的外键，并且是“单亲\u-to\u-ManyChild类型关系”）

因此，我想到了以下解决方案

1） 在子表中添加一个字段，该字段指向祖父母的PK字段（快速简单但多余，表示将来当人们希望搜索此子表时添加易用性）

2） 添加一个链接表，将祖父母中的PK链接到孩子中的PK（这似乎足够合理，并将导致只连接2个表的搜索）

3） 别管了，（未来的任何搜索都需要将孩子与父母和祖父母联系起来——这对这里的“非”程序员来说可能太多了！）。另外，目前我还没有被要求提供这个搜索，所以“对不起他们”，我确实提供了，但回答是“不，我们不需要”

4） 我还缺少一些其他的解决办法

就我个人而言，我倾向于使用解决方案#1，但我喜欢使用解决方案#3（出于血腥的想法），我可能会在开发说明中记录创建搜索所需的SQL

---

您的想法和其他解决方案非常受欢迎（例如阴影表和预创建联接表（在#3中，通过一个存储过程在有人打开应用程序时运行）。

很难用所有的“引号”来阅读这些内容，但在做过类似工作后，有一些想法：

我不喜欢创建不必要的表，有几个原因。首先，当源数据改变时，很容易忘记更新额外的表，所以事情会过时。如果确实创建了这些表，如果有一个或两个步骤来更新它们，请考虑一个宏来合并所有的更新步骤。第二，它是通用的。没有必要。所以我不喜欢你的选择2

出于同样的原因，我对选项1也有同样的感觉——我不喜欢创建额外的、不必要的字段，或者不得不担心让它们保持最新

这就剩下了选项3——对我来说，这听起来并不是一个坏选项。我看不出连接多个表的查询有任何基本问题。在您的情况下，祖父母-父母-孩子链接似乎很容易使用和理解。您可以将其设置为标准查询（而不是新表）这可以根据需要用于查找任何孩子的父母或祖父母，并用于将来需要开发的任何其他查询

---

至于“对他们很抱歉”-我一直认为项目是迭代的。展望未来和预测未来的需求是很好的，但我从来没有期望提前完全定义所有需求。每个答案和每个新功能似乎都会产生新的问题。要灵活。

经过思考，我更倾向于选项3，并且创建一个他们可以使用的标准查询。我可能会把它放在那里，而他们不会意识到这个存储的查询做了什么（我显然会记录它，但他们会阅读文档吗？）。