使用外键的SQL Server数据库设计

Question

我有以下部分数据库设计：

所有表都相互依赖，因此表bvd_docflow_subdocuments取决于表bdd_docflow_subsets

表格bvd_docflow_subdocuments取决于bvd_docflow_subsets。所以我认为我可以聪明并在每张桌子上使用外键（和ON DELETE CASCADE）。然而，FK正在深入研究如何进一步进入表格。

问题是表bvd_docflow_documents无法引用1docflow_documentset_id` PK / FK。有没有办法（也许我的设计很糟糕）只有站在它上面的桌子在桌子之间有一个FK关系而不是它上面的所有桌子。

修改

更多解释：

在bvd_docflow_subsets表中存储有关创建文档的对象的信息。该表与bvd_docflow_subdocuments表之间存在关系（此表存储有关子集的所有文档的主数据。（docflow_subset_id在两个表中）。这是表之间的链接。< / p>

进一步向下我们还得到了表bvd_docflow_documents这个表包含实际的文档数据。 bvd_docflow_documents和bvd_docflow_subdocuments之间的链接为bvd_docflow_subdocument_id。

在每个表上我都定义了一个外键，因此当在表上删除数据时，所有与该数据相关的数据也会被删除。

然而，当我们查看bvd_docflow_documents表时，它具有来自其他表的所有外键（docflow_subset_id和docflow_documentset_id），并且存在问题。 bvd_docflow_documents表所需的唯一外键是docflow_subdocument_id，而不是其他。

修改2

我进一步改变了我的设计并删除了初次导入数据后我不需要的信息。

有关（总）数据库设计的信息，请参阅以下链接： https://sqldbm.com/Project/SQLServer/Share/_AUedvNutCEV2DGLJleUWA

表subsets，subdocuments和documents有多对多的关系，所以我认为在我定义的3 documents_subdocuments之间有一个表格。这些表的所有不同键。

我不习惯数据库设计，然后构建它。但是，对于一切都是第一次，我尝试创建一个使用标准的数据库，并正确使用SQL Server的强大功能。

Answer 1

我会解决最底层的表格而忽略其余的表格。

但首先是一些评论。您的架构只是系统的模型。为了提供反馈，我们必须理解这个＆＃34;系统＆＃34;以及它如何实际评估您的模型。此外，了解您的实体以及选择它们的原因以及以指定方式对其进行建模非常重要。没有这种理解所有这些基于经验的猜测。

另一个评论。将标识列打包到每个表中只是懒惰的IMO建模。其他人会不同意，但你还需要强制执行所有自然键。你有自然钥匙吗？很少有任何。强制执行那些存在的。

最后一条评论。停止使用表名前置列名的荒谬模式。对于使用很长的表名，你应该认真思考。鉴于你拥有的东西，我觉得你需要一个你的docflow的架构。

对于文档表，您当前的PK没有意义。再一次，你已经在表格中打了一个标识栏。该列本身就是该表的关键。包含任何其他列不会使密钥再次成为＆＃34; unique＆＃34; - 包含是合乎逻辑的废话。按照您的模式，您可以将标识列指定为主键。但是......

根据您的图像，文档表与一个且仅一个子文档相关。您向该表添加了一个外键 - 它与图像匹配。您还向＆＃34;更高的＆＃34;添加了其他列和外键。表。所以现在一个文件＆＃34;点＆＃34;到一个特定的子文档。它还指向一个特定的子集 - 可能与子文档没有任何关系。同样的想法适用于其他FK。我怀疑这在逻辑上是否正确。那么为什么这些列（和相关的FK）存在呢？也许这是过早优化的结果 - 每个人都知道这是所有邪恶编码的根源。再一次，不可能知道这是不是＆＃34;对＆＃34;甚至＆＃34;有用＆＃34;为您的模型。

回答你的问题＆＃34; ...有没有方法＆＃34;，答案显然是肯定的。您删除了您抱怨的列。你添加了它们 - 为什么？这可能是您使用的工具的问题吗？

还有一些最后的评论。 ＆＃34; varchar（50）＆＃34;没有什么特别之处。也许这是一个将在以后更新的占位符。这也可能是懒惰的另一个迹象。一般来说，名称类似于＆＃34;类型＆＃34;和＃34;代码＆＃34;往往是＆＃34;查找＆＃34;的外键。表 - 因为人们喜欢随着时间的推移添加，修改或删除这些分类值。我还担心表间的列名重叠。 ＆＃34;位置＆＃34;存在于多个表中，action_code和action_id也存在。还有一个名为＆＃34; id＆＃34; （action_id）建议查找另一个表 - 是吗？应该是吗？ action_id和action_code之间是否存在关系？从远处看，不可能回答任何这些问题。

但设计数据库更多的是艺术而非科学。有时你只需要创建一些东西，用一些样本数据填充它，然后确定它是否适合你的需要。第一次尝试时，每个人都会出错。这是预期的;这就是你学习的方式。最困难的部分实际上是完成你的第一次尝试。