首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >在为我的主键选择数据类型时应该考虑什么?

问在为我的主键选择数据类型时应该考虑什么?
EN

Stack Overflow用户
提问于 2008-10-23 16:11:55
回答 16查看 2.1K关注 0票数 6

新建数据库表时,选择主键的数据类型需要考虑哪些因素?

EN

回答 16

Stack Overflow用户

回答已采纳

发布于 2008-10-24 10:10:54

很抱歉这么做,但我发现我给出的相关问题的答案(你可以查看this和this)可能适用于这个问题。我稍微重塑了一下它们。

你会发现很多关于这个问题的帖子,你所做的每一个选择都有它的优缺点。这些参数通常指的是关系数据库理论和数据库性能。

在这个问题上,我的观点很简单:代理主键总是有效的,而自然键可能并不总是有效的,这有多种原因:字段太短,规则改变,等等。

到目前为止,您已经猜到我基本上是唯一标识符/代理主键团队的成员,即使我欣赏和理解这里给出的论点,我仍然在寻找“自然”键比代理更好的情况……

除此之外,支持这一基本规则的一个最重要但总是被遗忘的论点是与代码规范化和生产力相关的

每次创建表时,I lose 都会丢失吗

每次我想要在我的code?

  • explaining my PK

  • 中将其引用给团队中的其他开发人员时,识别其主键和物理特征(键入,size)

  • remembering
  1. )的这些特征

对于所有这些问题,我的答案都是no:

  1. 当surrogate选项为我提供了一个万无一失的解决方案时,我没有时间去尝试确定“最佳的自然主键”。
  2. 当我写代码时,我不想记住我的Table_whatever的主键是一个10个字符的字符串。
  3. 我不想浪费我的时间来协商自然密钥的长度:“如果你需要10,为什么不取12 作为安全的呢?”这个“在安全方面”的论点真的让我很恼火:如果你想留在安全的一边,这意味着你真的离不安全的一边不远了!选择代理: it's bullet-proof!

所以我在过去的五年里一直在遵循一个非常基本的规则:每个表(让我们称之为'myTable')都有它的第一个字段,叫做'id_MyTable',它是uniqueIdentifier类型的。即使这个表支持“多对多”关系,其中一个字段组合提供了一个非常可接受的主键,我还是倾向于将这个'id_myManyToManyTable'字段创建为一个uniqueIdentifier,这只是为了遵守规则,而且最后,它也不会有什么坏处。

它的主要优点是,您不必再关心代码中主键和/或外键的使用。一旦有了表名,就知道了主键名称和类型。一旦知道了数据模型中实现了哪些链接,就知道了表中可用外键的名称。

如果您仍然希望将"Natural Key“放在表中的某个位置,我建议您按照标准模型进行构建,例如

代码语言:javascript
复制
Tbl_whatever

   id_whatever, unique identifier, primary key
   code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed
   .....

其中id_是主键的前缀,code_用于“自然”索引字段。有些人会争辩说code_字段应该设置为唯一。这是真的,可以通过DDL或外部代码轻松地管理它。请注意,许多“自然”键都是经过计算的(发票编号),因此它们已经通过代码生成

我不确定我的规则是不是最好的。但这是一个非常有效的方法!如果每个人都应用它,我们就可以避免浪费时间回答这类问题!

票数 11
EN

Stack Overflow用户

发布于 2008-10-23 16:14:52

如果使用数字键,请确保数据类型足够大,以容纳您可能希望表增长到的行数。

如果使用guid,是否需要考虑存储guid所需的额外空间?对应用程序的开发人员或用户来说,针对guid PKs进行编码会是一种痛苦吗?

如果使用组合键,您确定组合的列始终是唯一的吗?

票数 7
EN

Stack Overflow用户

发布于 2008-10-23 16:34:35

我真的不喜欢他们在学校里教的东西,那就是使用“自然关键字”(例如图书数据库上的ISBN ),甚至用2个或更多的字段组成一个主键。我永远不会那么做。所以这是我的小建议:

  • Always在每个表中都有一个用于主key.
  • They的专用列所有表在所有表中都应该具有相同的列名。"ID“或"GUID"
  • Use GUID(如果您不需要性能),否则递增INTs

编辑:

好吧,我想我需要稍微解释一下我的选择。

SQLSQL语句具有专用的列名并且在所有表中的主键都是相同的,这使得语句更容易构造,并且更容易让其他人(可能不熟悉您的数据库布局)更容易理解。尤其是当你在做大量的连接和类似的事情时。您不需要查找特定表的主键是什么,您已经知道了,因为它是相同的everywhere.

  • GUIDs和INTs,在大多数情况下并不是很重要。除非您达到了GUID的性能上限或执行数据库合并,否则您不会遇到任何重大问题。,但是,这是我更喜欢GUID的原因。GUID的全局唯一性总有一天会派上用场。也许您现在看不到它的需要,但是像将数据库的某些部分同步到笔记本电脑/手机,甚至查找数据记录而不需要知道它们在哪个表中,这些都是GUID可以提供的优势的很好的例子。整数仅标识一个表上下文中的记录,而GUID标识所有位置的记录。
票数 7
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/230351

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档