数据库应用程序设计。可以轻松扩展

Question

我觉得这有点“愚蠢”的问题，但无论如何，这可能对别人有用。 这也有点长，因为我想给我的情况提供背景。

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

问题（S）：
这些可能是敲问题，围绕我的prinicple的问题，您的想法是受欢迎的，如果它可能导致一个有趣的讨论，我很高兴打破每个点点进入一个新的问题，但我将这些东西包括在内以完成。

我有一个多路表，它们在'通路' 中相互连接，所以每个表都存储信息。为简单起见，您可以把它看作 项目：位置（地理）：亲临参观 （事实上这种途径中有另外4个表，但...） 由于每个位置可在每个项目中存在我有一个“project_2_location”表格将表格链接在一起 和其他每个中间表格之间的另一个“链接”表格。 所以如果表是A B C和D，链接表是 A_2_B：B_2_C：C_2_D：等等...（我不做A_2_C和A_2_D）。我还有一个'巨大'数量的2列'查找'表（实际上我有更多的'查找'类型表比我'真正'的表，这使我在'设计视图'agravates我）。

我的主要问题/问题。 我还有另外一组表格，这些表格引起了我的一些'悲伤'，如何继续下去。这是我的'问题'的根源。

我有2个表，在一个one_to_many relationsip链接，和我用父表中的“单”值链接到孩子（孩子都有自己的代理键）

显然，他们都没有特别对'孩子'表中的细节感兴趣，但是我创建了它，因为这是使界面工作最有利的方式，并且保持某种'第一范式'。现在

，我创造了这个子表，我知道他们将要在未来对其运行查询（即使此刻他们说，他们不！）。要做到这一点，他们将'有'创建一个连接，父母和他们granparent表，以提取他们想要的所有inormation。

所以在短暂的我有

Granparent（其作为项目名称的查找表）。

父母（它具有祖父母的PK的外键，并且是'oneGranparent_to_ManyParent类型关系）。

儿童（其中有一个外键家长的PK，是一个“oneParent_to_ManyChild类型的关系）。

所以我在脑海中有以下解决方案。

1）添加在一个领域中指向祖父母的PK场（快捷容易，但多余的，从将便于在未来，当人们想要搜索此子表）APPART孩子。

2）添加链接的PK在祖父母的PK中孩子一个链接表（这似乎不够reaonable，并且将导致连接只有2台搜索）

3）以及独自离开（任何未来的搜索都需要将孩子与父母和祖父母联系起来 - 这对于'非'程序员来说可能太多了！）。目前我还没有被要求提供这个搜索，所以'对不起'他们'，我确实提供它，但答复是'不，我们不会需要'

4）一些其他的解决方案我失踪。我个人倾向于使用解决方案＃1，但想用＃3（出于血腥头脑）运行，我可能会在开发笔记中记录创建搜索所需的SQL。

您的想法和其他解决方案都非常欢迎（如影子表和连接表（＃3预创建通过存储过程，每当有人打开的应用程序运行）。

Answer 1

很难阅读本与所有的'引号' - 但有几个想法做了类似的工作：

我不喜欢创建不必要的表，原因如下：首先，很容易忘记更新额外的表时，源数据发生变化，所以事情可能会变得过时。如果你创建这些表，如果有超过一个或两个步骤对其进行更新，考虑宏来整合所有的更新步骤;其次，它的通常是不必要的。因此，我不喜欢你的选项2.

我有选择1同样的感觉，出于同样的原因 - 我不喜欢创造额外的，不必要的字段，或担心保持它们的电流。

使叶片选项3 - 这听起来不像是一个坏的选择我。我没有看到任何加入多个表的查询的基本问题。在你的情况下，祖父母 - 父母 - 孩子链接似乎很容易使用和理解。您可以设置此成标准的查询（而不是新表），可以根据需要使用，以查找任何儿童的父母或祖父母，和你需要在未来开发的任何其他查询使用。

至于“这么对不起他们” - 我一直认为项目是重复的。很高兴展望未来，并预测未来的需求，但我从未期望预先充分确定所有需求。每个答案和每一个新的能力似乎总是会产生新的问题。变通。