【问题标题】:Multiple nullable foreign key vs multiple resource tables多个可为空的外键与多个资源表
【发布时间】:2019-04-16 16:09:44
【问题描述】:

我们正在设计一个系统,其中我们有两种类型的实体公司和财产。 Property 和 Company 都有自己的媒体资源(视频、照片),因此我们正在讨论在数据库级别处理此问题的两种方法。

首先是有一个媒体表,该表对公司和财产都有可为空的外键

第二个是对于 Company 和 Property 我们将有 CompanyMedia 和 PropertyMedia

这些方法中哪一种更有意义?

编辑:

应该因为提出解决方案 No2 而被杀:)。

【问题讨论】:

标签: database database-design foreign-keys relational-database


【解决方案1】:

第二种方法是禁止恕我直言。 media_urlmedia_type 属性在数据库中必须是唯一的。否则,您将面临重复和同步问题的风险。

型号 2 的问题示例:

  • 一个媒体链接到公司 1。它的类型是“视频”。
  • 相同的媒体(即 URL)链接到属性 1。它的类型是“博客”。
  • 如果您想要所有媒体及其类型的列表,现在会发生什么?你会选哪一个?
  • 而且你必须查询 2 个表,效率很低。

我在这里看到 4 张桌子。公司、财产、媒体和媒体类型。媒体类型也应该有自己的表,以避免重复。

因此:

Company
    idCompany
    CompanyName

Property
    idProperty
    PropertyName

Media
    idMedia
    MediaURL
    idMediaType, FK to MediaType

MediaType
    idMediaType
    Type

还有链接表:

Property_has_Media
    idProperty
    idMedia

Company_has_Media
    idCompany
    idMedia

型号:

我建议如果一种媒体永远不会同时与公司和财产相关联,我建议采用这种结构。从你的问题来看,这是我的理解。从概念上讲,媒体没有定义公司和财产之间的链接,因此拥有 2 个单独的链接表更有意义。它还将避免在您的查询中出现“IS NOT NULL”。

【讨论】:

  • 哇。我不敢相信我已经建议解决方案 2 作为可能的答案。基本上,我在脑海中想到了您提出的解决方案(只是没有 MediaType 作为单独的表格)。因此,我将根据您的修改选择 No2 选项 :)。财产和公司永远不应拥有相同的媒体(即使它们是相关的,但公司拥有许多财产)
  • :-) SO 提供了第二双眼睛!
  • @kljuco 你的#1 是实现继承/子类型的常见反模式。您的#2 也没有标准化问题。 (您可能不喜欢使用联合,这是答案中提到的超类型查询所必需的(尽管它是暗示存在问题的修辞问题),但有一些变体可以避免这种情况。)请参阅重复链接和许多其他类似的链接选项的继承/子类型/多态性。
  • 按照他设置 #2 的方式,您在添加新的媒体表时不必扫描两个媒体表以避免重复吗?当然,除非您已经知道它将是公司或财产媒体。在这种情况下,我提出的结构不是更通用吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-07-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-12-12
  • 2021-04-28
  • 1970-01-01
相关资源
最近更新 更多