主页 / dba / 问题 / 24903
Accepted
EBarr
Asked: 2012-09-26 11:19:37 +0800 CST

设计模式 - 许多父表之一

  • 772

我经常在数据库中遇到一种情况，其中给定的表可以 FK 到许多不同的父表之一。我已经看到了解决这个问题的两种方法，但都不是个人满意的。我很好奇你还看到了哪些其他模式？有更好的方法吗？

一个人为的例子
假设我的系统有Alerts. 可以接收各种对象的警报——客户、新闻和产品。给定的警报可以针对一项且仅一项。无论出于何种原因，客户、文章和产品都在快速移动（或本地化），因此在创建警报时无法将必要的文本/数据提取到警报中。鉴于此设置，我已经看到了两种解决方案。

注意：下面的 DDL 适用于 SQL Server，但我的问题应该适用于任何 DBMS。

解决方案 1 -- 多个可为空的 FKey

在此解决方案中，链接到多表之一的表具有多个 FK 列（为简洁起见，以下 DDL 未显示 FK 创建）。 好的- 在这个解决方案中，我有外键很好。FK 的零可选性使得添加准确数据变得方便且相对容易。不好的查询不是很好，因为它需要N LEFT JOINS 或N UNION 语句来获取相关数据。在 SQL Server 中，特别是 LEFT JOINS 会阻止创建索引视图。

CREATE TABLE Product (
    ProductID    int identity(1,1) not null,
    CreateUTC    datetime2(7) not null,
     Name        varchar(100) not null
    CONSTRAINT   PK_Product Primary Key CLUSTERED (ProductID)
)
CREATE TABLE Customer (
    CustomerID  int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
     Name       varchar(100) not null
    CONSTRAINT  PK_Customer Primary Key CLUSTERED (CustomerID)
)
CREATE TABLE News (
    NewsID      int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
    Name        varchar(100) not null
    CONSTRAINT  PK_News Primary Key CLUSTERED (NewsID)
)

CREATE TABLE Alert (
    AlertID     int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
    ProductID   int null,
    NewsID      int null,
    CustomerID  int null,
    CONSTRAINT  PK_Alert Primary Key CLUSTERED (AlertID)
)

ALTER TABLE Alert WITH CHECK ADD CONSTRAINT CK_OnlyOneFKAllowed 
CHECK ( 
    (ProductID is not null AND NewsID is     null and CustomerID is     null) OR 
    (ProductID is     null AND NewsID is not null and CustomerID is     null) OR 
    (ProductID is     null AND NewsID is     null and CustomerID is not null) 
)

解决方案 2 - 每个父表中的一个 FK
在此解决方案中，每个“父”表都有一个到警报表的 FK。它使检索与父级关联的警报变得容易。不利的一面是，从警报到谁引用没有真正的链。此外，数据模型允许孤立警报——其中警报与产品、新闻或客户无关。同样，多个 LEFT JOIN 来找出关联。

CREATE TABLE Product (
    ProductID    int identity(1,1) not null,
    CreateUTC    datetime2(7) not null,
     Name        varchar(100) not null
    AlertID     int null,
    CONSTRAINT   PK_Product Primary Key CLUSTERED (ProductID)
)
CREATE TABLE Customer (
    CustomerID  int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
     Name       varchar(100) not null
    AlertID     int null,
    CONSTRAINT  PK_Customer Primary Key CLUSTERED (CustomerID)
)
CREATE TABLE News (
    NewsID      int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
    Name        varchar(100) not null
    AlertID     int null,
    CONSTRAINT  PK_News Primary Key CLUSTERED (NewsID)
)

CREATE TABLE Alert (
    AlertID     int identity(1,1) not null,
    CreateUTC   datetime2(7) not null,
    CONSTRAINT  PK_Alert Primary Key CLUSTERED (AlertID)
)

这只是关系数据库中的生活吗？是否有您发现更令人满意的替代解决方案？

database-design

2 个回答

  1. Best Answer

    我理解第二种解决方案不适用，因为它不提供一个（对象）对多（警报）关系。

    由于严格的 3NF 合规性，您只能使用两种解决方案。

    我会设计一个较小的耦合模式：

    CREATE TABLE Product  (ProductID  int identity(1,1) not null, ...)
CREATE TABLE Customer (CustomerID int identity(1,1) not null, ...)
CREATE TABLE News     (NewsID     int identity(1,1) not null, ...)

CREATE TABLE Alert (
  -- See (1)
  -- AlertID     int identity(1,1) not null,

  AlertClass char(1) not null, -- 'P' - Product, 'C' - Customer, 'N' - News
  ForeignKey int not null,
  CreateUTC  datetime2(7) not null,

  -- See (2)
  CONSTRAINT  PK_Alert Primary Key CLUSTERED (AlertClass, ForeignKey)
)

-- (1) you don't need to specify an ID 'just because'. If it's meaningless, just don't.
-- (2) I do believe in composite keys

    或者，如果完整性关系是强制性的，我可以设计：

    CREATE TABLE Product  (ProductID  int identity(1,1) not null, ...)
CREATE TABLE Customer (CustomerID int identity(1,1) not null, ...)
CREATE TABLE News     (NewsID     int identity(1,1) not null, ...)

CREATE TABLE Alert (
  AlertID     int identity(1,1) not null,
  AlertClass char(1) not null, /* 'P' - Product, 'C' - Customer, 'N' - News */
  CreateUTC  datetime2(7) not null,
  CONSTRAINT  PK_Alert Primary Key CLUSTERED (AlertID)
)

CREATE TABLE AlertProduct  (AlertID..., ProductID...,  CONSTRAINT FK_AlertProduct_X_Product(ProductID)    REFERENCES Product)
CREATE TABLE AlertCustomer (AlertID..., CustomerID..., CONSTRAINT FK_AlertCustomer_X_Customer(CustomerID) REFERENCES Customer)
CREATE TABLE AlertNews     (AlertID..., NewsID...,     CONSTRAINT FK_AlertNews_X_News(NewsID)             REFERENCES News)

    反正...

    三个有效的解决方案加上另一个被考虑用于许多（对象）对一个（警报）关系......

    这些呈现出来，有什么寓意？

    它们有细微的不同，并且在标准上的权重相同：

    • 插入和更新的性能
    • 查询复杂度
    • 储存空间

    所以，选择适合你的那个。

    • 4

  2. 我使用了触发器维护的连接表。如果重构数据库是不可能或不可取的，该解决方案作为最后的手段效果很好。这个想法是你有一个表来处理 RI 问题，所有 DRI 都反对它。

    • 1

相关问题