【问题标题】:Relational database design considering partly dependent information?考虑部分依赖信息的关系数据库设计?
【发布时间】:2015-07-10 03:45:41
【问题描述】:

我有强烈的感觉,我只见树木不见森林,所以我需要你的帮助。

想想下面两张表:

create table Category (Category_ID    integer,
                       Category_Desc  nvarchar2(500));

create table Text (Text_Id       integer,
                   Text          nvarchar2(1000),
                   Category_Id   integer references Category.Category_Id);

这段代码没有遵循正确的语法,只是为了了解问题。

考虑保存某些类别的文本部分以在界面中使用它们的想法,例如消息(“你不能这样做!”,“这样做!”,...),但也可以创建注释其他对象,例如。 G。喜欢订单(“重要客户!优先考虑此订单!”)。

现在回答我的问题。其中一些文本位带来了更多信息,例如,如果您将“重要客户”注释添加到订单中,则Order.Prio_Flag 也已设置。

现在这是一个非常特殊的信息,仅考虑类别 Order_Note 使用的文本。我不想将其添加到 Text 表中,因为大多数条目不受此影响,并且表会因为仅其内容的最少部分的特殊情况而变得越来越拥挤。

我明白,设计有缺陷,但我也不希望每个类别都有一个表格,并尽可能保持通用。

请记住,这是对问题的简化视图。

TL:DR:如何在不添加新属性的情况下向表格内容添加信息,因为新属性只会填充最少的条目。

【问题讨论】:

    标签: database database-design relational-database


    【解决方案1】:

    子类型和依赖属性在关系数据库中很容易实现。例如,如果某些Texts 很重要并且需要具有依赖属性(例如DisplayColor),您可以将下表添加到您的架构中:

    CREATE TABLE ImportantText (
        Text_Id integer NOT NULL ,
        Display_Color integer NOT NULL ,
        PRIMARY KEY (Text_Id),
        CONSTRAINT ImportantTextSubtypeOfText
            FOREIGN KEY (Text_Id) REFERENCES Text (Text_Id)
            ON DELETE CASCADE ON UPDATE CASCADE
    );
    

    许多人认为外键约束建立实体之间的关系。这不是他们的目的。它们是约束,即它们将列中的值限制为另一列的子集。这样就建立了一个可以记录附加属性的子类型关系。

    在上表中,ImportantText 的任何元素都必须是Text 的元素,并且将具有Text 的所有属性(因为它必须记录在Text 表中),以及ImportantText 的附加属性。

    【讨论】:

    • 正如您所提到的,这很明显。非常感谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多