如何设计SQL查找表答案

【问题标题】：How to design SQL lookup table如何设计SQL查找表
【发布时间】：2015-05-02 15:46:53
【问题描述】：

我不完全确定如何表达标题，这就是为什么我很难用谷歌搜索解决方案。

我已经有几年没有做 SQL 建模和设计了，最近又开始涉足了。

我的问题是这样的：

我有一个唯一的 ProjectID 列表。

有些项目对其他项目有“墙”，这意味着来自一个项目的人对另一个项目一无所知。我想通过隐藏列来在报告中实现此逻辑，如果此人是一个项目的成员，其中一个“WallFlags”针对它。

验证此人所属的项目已解决。

关系是零还是多，

我想要什么：

我想要一种永久的、可扩展的方式来存储这些信息。我正计划构建一个存储项目 id 的表，但我无法概念化如何记录一个项目与多个其他项目存在冲突的情况...

另外，如果有人知道有助于设计的资源，我将不胜感激，这样我就可以开始工作了

【问题讨论】：

我的第一个 SWAG 将是您需要 Projects、People、PeopleProjects 的表来将人员分配给零个或多个项目，并需要 ProjectWalls 来识别由分隔的项目对虚拟护城河。我可能会继续添加触发器，以确保您不能将一个人分配给两个彼此相隔多远的项目，并处理可能分裂一个人的项目墙的更改。可以写TVF返回，比如PersonId的所有项目不禁止查看。

【解决方案1】：

如果一个人是两个项目的成员，每个项目都有墙，你会怎么做？

Walls:  ProjIDbase, ProjIDblocked

【讨论】：

我相当肯定我们公司的法律部门确保不会发生这种情况。我喜欢墙桌的想法。 PK 可能是随机的，我也会输入一个既定的日期。也许是一个活跃的旗帜。我想避免现在用标志在每个项目中添加十行，但我看不出有什么办法
为什么不直接用这两列作为PK呢？
您认为另一个不必要的列更简单或更准确？那是自然键，您应该使用它。该表有一个自然的复合键，您认为忽略它会使事情变得更好吗？
这改变了敌意的语气。是的，我确实认为加入代理键比加入复合键更简单。无论如何，我感谢您对此事的意见，如果您知道与性能相关的缺点，我很想听听他们的意见。我相对较新，虽然自然键很好，但我发现统一的代理键更容易让我之后的人识别并快速开始使用（使用正确的设计）
但它的设计不正确。自然键的哪一部分是复合的还不清楚。你认为 3NF 仅仅是一个性能的东西？去做对你来说容易的事。如果你要做对你来说容易的事情，为什么要问一个问题？你喜欢 PK 作为“CharCharIntIntIntIntInt”——你知道这有多幼稚吗？