【问题标题】:Reference to table without foreign key constraint引用无外键约束的表
【发布时间】:2012-12-19 02:28:56
【问题描述】:

我有一个数据库和一个编辑数据库的应用程序

我有一个名为 ADDRESS (ID, STREETID, NUMBER) 的地址表

我有一个名为 STREET (ID, STREETNAME, CREATIONUSERID) 的街道名称表

我还有一个名为 USER (ID, USERNAME, PASSWORD) 的用户表

我的表 STREET 中的街道名称已经填满。 该表被用户用作查找表 在我的应用程序的某处输入地址(字段 ADDRESS.STREETID), 但有时用户必须输入一条新街道 将插入 STREET 以供进一步使用。 当用户在我的桌子上添加一条街道时,我希望能够 跟踪哪个用户进行了添加。

我现在有两个选择:

第一个:创建一个虚假用户,其中 STREET 的默认街道 将引用然后创建一个外键约束 (STREET.CREATIONUSERID 指 USER.ID) 用于创建的新街道

第二个:不创建外键约束,将 CREATIONUSERID 留空 对于 STREET 的默认街道并仅针对新街道进行更新 创建街道以跟踪添加每个街道的用户

哪个更好,为什么?

【问题讨论】:

    标签: database-design foreign-keys relationship


    【解决方案1】:

    最好使用外键,这样可以保证参照完整性

    Check the link for the advantages of foreign key

    【讨论】:

    • 感谢您的链接。阅读它,我刚刚意识到外键可以有 NULL 值,所以这对我来说是最好的解决方案。我将为 CREATIONUSERID 创建一个外键约束,同时使其“可为空”
    【解决方案2】:

    当您系统中的某个用户不再是一个用户并且必须从您的 USER 表中删除时,您打算做什么?

    【讨论】:

    • 我还有一个字段 USER.STATUS,它是用户状态的标志。如果必须删除用户,我会将其设置为“已删除”。这样我可以保留该用户的历史记录,同时将他设置为非活动状态。
    猜你喜欢
    • 2021-05-13
    • 1970-01-01
    • 1970-01-01
    • 2019-11-30
    • 1970-01-01
    • 2021-02-19
    • 1970-01-01
    • 2020-03-28
    • 1970-01-01
    相关资源
    最近更新 更多