当前位置：文江博客话题详情

主键与 RRN

发布于 2024-08-26 08:25:14 字数 21 浏览 2 评论 0原文

主键和 RRN 有什么区别？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

爱已欠费 2024-09-02 08:25:14

主键唯一且明确地标识给定记录（在数据库表/视图中）或给定行（在文本文件中）。虽然主键基于单个字段（单个“列”）可能很方便，但主键也可能基于多个字段/列。

RRN 是一个缩写词，可以理解为“记录行号”或“相对行号”。记录行号通常被理解为一个数字，通常（但不一定）通过简单增量（基于先前分配的 RRN 的值）分配，该增量被“添加”到特定记录类型的其他字段/列。许多 DBMS 提供支持此类“自动递增”或更普遍的自动分配 RRN 的功能。

如上所述，RRN 可以用作主键。

与基于记录的[一个或多个]属性（字段或列）值的主键相比，拥有[语义无效] RRN 有许多优点和缺点。这可能在其他 SO 问题中讨论过；以下是一些最常见的参数：

主键可以修改，RRN 是“不可变的”。
例如，如果主键是社会安全号码 (SSN)，则记录有时可能会更新，因为 SSN 最初输入时存在拼写错误。当/如果发生这种情况，任何使用此 SSN 引用更新记录的相关记录也需要更新。如果这些相关记录使用[非有意义的] RRN，它们将不会受到 SSN 值可能发生的变化的影响。
当没有基于单列的“自然”主键时，使用 RRN 可能更方便 RRN
通常较短
相关表和列表通过非 RRN 主键引用原始记录，以某种方式重复基础信息。这既可以是优点，也可以是缺点：无需在原始表中查找即可知道基础字段值：如果您希望相关表包含此类信息，则很好，如果不包含此类信息，则不好（例如：社交安全号可以被认为是敏感的等。）
RRN 保证是唯一的（没有 RRN 生成逻辑的错误），因此基于属性值的密钥有变成非唯一的倾向（“哎呀！我们以为我们可以使用电话号码作为房屋 ID；该死！电话公司开始重复使用号码……”）

A Primary key uniquely and unambiguously identifies a given record (in a database table/view) or a given row (in a text file). Although it can be convenient for the primary key to be based on a single Field (a single "column"), it is also possible for a primary to be based on several Fields/Columns.

RRN is an acronym which can either be understood as "Record Row Number" or "Relative Row Number". The Record Row Number is generally understood to be a number, typically (but not necessarily) assigned by simple increment (based on the value of the previous such RRN assigned) which is "added" to the other Fields/Column of a particular record type. Many DBMSes supply features for the support of such "auto-incremented" or more generally automatically assigned RRNs.

Defined as above, an RRN can be used as a Primary Key.

There are many advantages -and drawbacks- to having a [semantically void] RRN as opposed to a Primary key based on [one or several] attribute (Field or Column) values of the record. This is probably discussed in other SO question; here are a few of the most common arguments:

A primary key may be modified, an RRN is "immutable".
For example if the primary key is a Social Security Number (SSN), a record may at some time be updated because the SSN was originally input with a typo error. When/if that happens, any related records which uses this SSN to refer to the updated record need to also be updated. Had these related records used the [non significative] RRN, they would be immune to possible changes of the SSN value.
When there is no "natural" Primary key based on a single column, it may be more convenient to use the RRN
RRNs are typically shorter
Related tables and lists which refer to original records by way of a non-RRN primary key, somehow duplicate the underlying information. This can be both an advantage and a drawback: one can know the underlying field value without having to look it up in the original table: good if you want the related table to contain such info, bad if you don't (ex: Social Security Number can be considered sensitive etc.)
RRNs are guaranteed to be unique (short of a bug with the RRN-generation logic), whereby attribute-value based keys have a propensity to turning out non-unique ("oops! We thought we could use phone number as a house ID; dang!, the phone company started reusing numbers...")

回复收藏 0 原文