我应该在每个表中使用ID,为什么要在多对多关系中创建联接表

问题描述 投票:0回答:2

[在许多教程和大学中,人们说我应该在每个表中都使用id列作为主键,并且在多对多关系中,我应该创建新表来连接它们。

  1. 使用id代替将唯一的varchar设置为主键有什么好处?我在堆栈上读到,并非所有开发人员都这样做,但这仅仅是更改varchar的问题,还是使用int效率更高,效率更高多少?

  2. << role_id?如果在具有ID字段的联接表中仍然存在重复项,有什么区别?
  • 我正在使用Firebird,但我想在其他数据库中也是如此。
  • sql firebird
    2个回答
    0
    投票
      与varchar one相比,自动创建和填充唯一ID要容易得多。如果您打算使用真实数据(例如项目代码等)作为主键,则您(您的客户)或早或晚需要进行更改-但这往往会破坏所有外键关系,日志,档案等。 (长)整数作为ID,则通常也需要较少的存储空间。
    1. 在设计合理的数据库结构中,您没有重复项。好吧,ID本身被复制为外键,但数据不是。如果在很多情况下都没有属性表或关系表,那么(以您的示例为例)您将开始拥有('john', 'admin', 'admin_desc')('john', 'user', 'user_desc')('jane', 'admin', 'user_desc')等记录-如何从中删除所有角色用户或更改用户名,或者“管理员”角色说明到底是什么?您应尽可能避免重复数据。


    0
    投票
    另一个关注点是使用ProductName作为关键字段。

    这通常是个坏主意,原因有很多(至少三个)。通常,您需要一个整数数字ID和一个单独的表,该表包含产品的每个合成ID的名称和其他

    attributes

    另请参见:

    Surrogate vs. natural/business keys


    您不“仅使用” ID,还向其添加了约束和限制,无论是显式的还是隐式的。只需选择VarChar(NN)数据类型-您就可以为数据长度添加限制。通过选择BLOB SUB_TYPE TEXT-您通常会停用唯一索引和相关功能(FKeyed表中的GROUP BY等)。使用

    自然键

    时,请始终添加此约束或该约束。无论您是否全部意识到。

    我们有一个内部系统由于草皮战争而失败。没有办法解决它。我们必须建立一个替换系统,并且从一开始就将“截止日期定为昨天”。每天我们都可以刮掉重要的东西。

    因此,我屈从于Natural Key的想法,并使用了州官方的Unique Taxpayer ID作为数据ID。我问我们公司中的每个人,我都可以知道唯一的国家授权ID是否唯一。他们都清除了这个主意。它节省了我几个小时的调试时间,简化了生产和错误查找查询。那确实很重要。

    [投入生产的几个月后,我们无法注册新合同-事实证明,大型银行违反了州法律,并要求自己在某些情况下可以共享唯一的纳税人ID(该许可证后来被撤销,但那时它很活跃,并且使用)。

    现在我有一个实时系统,不能仅仅从业务流程中删除它。而且,我必须重新执行部分数据库结构并重新执行部分用户界面,以提供要复制的自然主键。还有另一个“昨天”的截止日期。

    我将其删减后,又做了一个澄清。事实证明,虽然我们没有开拓国外市场,但是一些进入国内市场的外国公司也购买了我们的产品。猜猜是什么,他们的前一个纳税人ID与当地法律相符。它们只是不适合我们国内法律驱动的数据类型,CHECK CONSTRAINT和UI代码。我不得不再次修改它们,尽管这次的工作量要少得多。

    尽管,我知道Natural ID将是进一步发展的基础,我已尽一切努力确保规格在该方面是最终的,并且不会进行进一步的发展。我什至得到了各种各样的承诺。几个月后就被解雇了。

    保持警告状态。

    © www.soinside.com 2019 - 2024. All rights reserved.