Первичный ключ однозначно и однозначно идентифицирует данную запись (в таблице / представлении базы данных) или данную строку (в текстовом файле).Хотя может быть удобно, чтобы первичный ключ основывался на одном поле (одном «столбце»), первичный ключ также может основываться на нескольких полях / столбцах.
RRN является аббревиатурой, которую можно понимать как « Номер строки записи » или « Относительный номер строки ».Номер строки записи обычно понимается как число, обычно (но не обязательно), назначаемое простым приращением (на основе значения предыдущего такого назначенного RRN), которое «добавляется» в другие поля / столбцы определенного типа записи.,Многие СУБД предоставляют функции для поддержки таких «автоматически инкрементных» или, в более общем случае, автоматически назначаемых RRN.
Как указано выше, RRN может использоваться в качестве первичного ключа.
Существует многоПреимущества - и недостатки - наличие [семантически недействительного] RRN по сравнению с первичным ключом на основе [одного или нескольких] значений атрибута (поля или столбца) записи.Это, вероятно, обсуждается в другом вопросе SO;Вот несколько наиболее распространенных аргументов:
- Первичный ключ может быть изменен, RRN является «неизменяемым».
Например, если первичным ключом является номер социального страхования (SSN)запись может быть обновлена через некоторое время, потому что SSN был первоначально введен с ошибкой опечатки.Когда / если это происходит, любые связанные записи, которые используют этот SSN для ссылки на обновленную запись, также должны быть обновлены.Если бы в этих связанных записях использовался [несущественный] RRN, они были бы невосприимчивы к возможным изменениям значения SSN. - Когда нет «естественного» первичного ключа, основанного на одном столбце, это может быть более удобнымдля использования RRN
- RRN обычно короче
- Связанные таблицы и списки, которые ссылаются на оригинальные записи посредством первичного ключа не-RRN, каким-то образом дублируют основную информацию.Это может быть как преимуществом, так и недостатком: можно узнать значение базового поля без необходимости искать его в исходной таблице: хорошо, если вы хотите, чтобы соответствующая таблица содержала такую информацию, плохо, если вы этого не сделаете (например, SocialЗащитный номер может считаться конфиденциальным и т. Д.)
- RRN гарантированно будут уникальными (если не считать ошибки с логикой генерации RRN), при этом ключи на основе значений атрибутов имеют склонность к тому, чтобы оказаться неуникальными («Ой! Мы думали, что можем использовать номер телефона в качестве идентификатора дома; черт!, телефонная компания начала повторно использовать номера ...»)