Question

What’s the difference between a primary key and an RRN?

Answer 1

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…”)