[在许多教程和大学中,人们说我应该在每个表中都使用id列作为主键,并且在多对多关系中,我应该创建新表来连接它们。
使用id代替将唯一的varchar设置为主键有什么好处?我在堆栈上读到,并非所有开发人员都这样做,但这仅仅是更改varchar的问题,还是使用int效率更高,效率更高多少?
在设计合理的数据库结构中,您没有重复项。好吧,ID本身被复制为外键,但数据不是。如果在很多情况下都没有属性表或关系表,那么(以您的示例为例)您将开始拥有('john', 'admin', 'admin_desc')
,('john', 'user', 'user_desc')
,('jane', 'admin', 'user_desc')
等记录-如何从中删除所有角色用户或更改用户名,或者“管理员”角色说明到底是什么?您应尽可能避免重复数据。
ProductName
作为关键字段。 这通常是个坏主意,原因有很多(至少三个)。通常,您需要一个整数数字ID和一个单独的表,该表包含产品的每个合成ID的名称和其他
attributes
。另请参见:
Surrogate vs. natural/business keys
VarChar(NN)
数据类型-您就可以为数据长度添加限制。通过选择BLOB SUB_TYPE TEXT
-您通常会停用唯一索引和相关功能(FKeyed表中的GROUP BY
等)。使用自然键
时,请始终添加此约束或该约束。无论您是否全部意识到。我们有一个内部系统由于草皮战争而失败。没有办法解决它。我们必须建立一个替换系统,并且从一开始就将“截止日期定为昨天”。每天我们都可以刮掉重要的东西。
因此,我屈从于Natural Key的想法,并使用了州官方的Unique Taxpayer ID作为数据ID。我问我们公司中的每个人,我都可以知道唯一的国家授权ID是否唯一。他们都清除了这个主意。它节省了我几个小时的调试时间,简化了生产和错误查找查询。那确实很重要。[投入生产的几个月后,我们无法注册新合同-事实证明,大型银行违反了州法律,并要求自己在某些情况下可以共享唯一的纳税人ID(该许可证后来被撤销,但那时它很活跃,并且使用)。
现在我有一个实时系统,不能仅仅从业务流程中删除它。而且,我必须重新执行部分数据库结构并重新执行部分用户界面,以提供要复制的自然主键。还有另一个“昨天”的截止日期。
我将其删减后,又做了一个澄清。事实证明,虽然我们没有开拓国外市场,但是一些进入国内市场的外国公司也购买了我们的产品。猜猜是什么,他们的前一个纳税人ID与当地法律相符。它们只是不适合我们国内法律驱动的数据类型,CHECK CONSTRAINT
和UI代码。我不得不再次修改它们,尽管这次的工作量要少得多。
尽管,我知道Natural ID将是进一步发展的基础,我已尽一切努力确保规格在该方面是最终的,并且不会进行进一步的发展。我什至得到了各种各样的承诺。几个月后就被解雇了。
保持警告状态。