新建数据库表时,选择主键的数据类型需要考虑哪些因素?
发布于 2008-10-24 10:10:54
很抱歉这么做,但我发现我给出的相关问题的答案(你可以查看this和this)可能适用于这个问题。我稍微重塑了一下它们。
你会发现很多关于这个问题的帖子,你所做的每一个选择都有它的优缺点。这些参数通常指的是关系数据库理论和数据库性能。
在这个问题上,我的观点很简单:代理主键总是有效的,而自然键可能并不总是有效的,这有多种原因:字段太短,规则改变,等等。
到目前为止,您已经猜到我基本上是唯一标识符/代理主键团队的成员,即使我欣赏和理解这里给出的论点,我仍然在寻找“自然”键比代理更好的情况……
除此之外,支持这一基本规则的一个最重要但总是被遗忘的论点是与代码规范化和生产力相关的
每次创建表时,I lose 都会丢失吗
每次我想要在我的code?
对于所有这些问题,我的答案都是no:
所以我在过去的五年里一直在遵循一个非常基本的规则:每个表(让我们称之为'myTable')都有它的第一个字段,叫做'id_MyTable',它是uniqueIdentifier类型的。即使这个表支持“多对多”关系,其中一个字段组合提供了一个非常可接受的主键,我还是倾向于将这个'id_myManyToManyTable'字段创建为一个uniqueIdentifier,这只是为了遵守规则,而且最后,它也不会有什么坏处。
它的主要优点是,您不必再关心代码中主键和/或外键的使用。一旦有了表名,就知道了主键名称和类型。一旦知道了数据模型中实现了哪些链接,就知道了表中可用外键的名称。
如果您仍然希望将"Natural Key“放在表中的某个位置,我建议您按照标准模型进行构建,例如
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed
.....其中id_是主键的前缀,code_用于“自然”索引字段。有些人会争辩说code_字段应该设置为唯一。这是真的,可以通过DDL或外部代码轻松地管理它。请注意,许多“自然”键都是经过计算的(发票编号),因此它们已经通过代码生成
我不确定我的规则是不是最好的。但这是一个非常有效的方法!如果每个人都应用它,我们就可以避免浪费时间回答这类问题!
发布于 2008-10-23 16:14:52
如果使用数字键,请确保数据类型足够大,以容纳您可能希望表增长到的行数。
如果使用guid,是否需要考虑存储guid所需的额外空间?对应用程序的开发人员或用户来说,针对guid PKs进行编码会是一种痛苦吗?
如果使用组合键,您确定组合的列始终是唯一的吗?
发布于 2008-10-23 16:34:35
我真的不喜欢他们在学校里教的东西,那就是使用“自然关键字”(例如图书数据库上的ISBN ),甚至用2个或更多的字段组成一个主键。我永远不会那么做。所以这是我的小建议:
编辑:
好吧,我想我需要稍微解释一下我的选择。
SQLSQL语句具有专用的列名并且在所有表中的主键都是相同的,这使得语句更容易构造,并且更容易让其他人(可能不熟悉您的数据库布局)更容易理解。尤其是当你在做大量的连接和类似的事情时。您不需要查找特定表的主键是什么,您已经知道了,因为它是相同的everywhere.
https://stackoverflow.com/questions/230351
复制相似问题