【问题标题】:Database design for 1-1 where one side foreign key references more than one tables?1-1的数据库设计,其中一侧外键引用多个表?
【发布时间】:2016-09-22 07:21:13
【问题描述】:

背景

我有一个用于从平面文件导入数据的应用程序。有一个 ImportJob 表,其中包含导入作业详细信息(作业名称、作业计划等)和源文件配置详细信息(文件名、文件格式等)。

现在,我需要添加更多数据源,以便应用程序可以从数据库、Web 服务等导入数据。

每个导入作业始终只有一个数据源。

当前(简化的)表结构 -

ImportJob - Id, JobName, JobStartTime, SourceFileName, SouceFileDelimiter

问题 我应该如何重组它,以便我可以添加更多源类型,但仍确保每个导入作业只有一种源类型? (在 Sql Server 中)

我正在考虑以下解决方案 -

  1. 将新源类型的列添加到同一个表中,并使用“SourceType”字段来确定从哪些列获取数据 -

    ImportJob table - Id, JobName, JobStartTime, SourceType, SourceFileName, SourceFileDelimiter, SourceWebServiceLink, SourceWebServiceUserName, SourceDBServer, SourceDBName etc
    

    问题 - 对于任何源类型,大多数列都是空的。随着越来越多的来源被添加,该表可能会变得非常宽(并且非常空)。

  2. 为每个源创建单独的“源”表,并在 ImportJob 表中使用“共享”外键引用它们 -

    ImportJob table - Id, JobName, JobStartTime, SourceType, SourceId (foregin key)
    SourceFile table - SourceId (primary), SourceFileName, SourceFileDelimiter
    SourceWebService table - SourceId (primary), SourceWebServiceLink, SourceWebServiceUserName
    SourceDB table - SourceId (primary), SourceDBServer, SourceDBName
    

    问题 - 应用程序将使用 ImportJob 中的 SourceType 字段来确定密钥所属的 SourceXXX 表。另外,ImportJob 中的 SourceType 和 SourceId 之间的关系是不强制的。

是否有任何标准/理想的建模方式?

【问题讨论】:

    标签: sql-server database


    【解决方案1】:

    两者都有效。示例一非常简单易懂,只要来源很少,但最终您应该重构为示例二。我想我会更改示例二以模仿这样的“继承”,因此表结构/命名“传达”意图:

    ImportJob – Id、JobName... Source_Id (FK)

    来源 – Id (PK)、类型

    SourceFile – Source_Id (PK/FK), ....

    SourceWebService – Source_Id (PK/FK), ....

    或者像这样:

    ImportJob – Id、JobName、类型...

    ImportJobSourceFile – ImportJob_Id (PK/FK), ....

    ImportJobSourceWebService – ImportJob_Id (PK/FK), ....

    它仍然没有 100% 强制执行关系,但是您有一个可能限制错误的约定。如果您仍然希望系统严格执行规则(“一对一约束”),那么您应该检查一下为您的数据库供应商系统实现表继承的快速简报。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-05-13
      • 1970-01-01
      • 1970-01-01
      • 2012-05-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多