ограничения внешнего ключа для столбцов первичного ключа - проблемы?

Question

Каковы плюсы / минусы с точки зрения производительности / индексации / управления данными в создании взаимно-однозначных отношений между таблицами, использующими первичный ключ дочернего элемента в качестве внешнего ключа, по сравнению с чистым суррогатным первичным ключом дочернего элемента? Первый подход, по-видимому, уменьшает избыточность и приятно неявно ограничивает взаимно-однозначное отношение, в то время как администраторы БД предпочитают второй подход, хотя он создает второй индекс:

create table parent (
     id integer primary key, 
     data varchar(50)
)

create table child (
     id integer primary key references parent(id), 
     data varchar(50)
)

чистый суррогатный ключ:

create table parent (
     id integer primary key, 
     data varchar(50)
)

create table child (
     id integer primary key,
     parent_id integer unique references parent(id), 
     data varchar(50)
)

представляющими интерес платформами здесь являются Postgresql, Microsoft SQL Server.

Edit:

Итак, вот основная идея настоящего администратора баз данных. Основное беспокойство вызывает фрагментация индекса дочерней таблицы. Предположим, что записи с первичными ключами 1-1000000 вставлены в родительскую таблицу, а в дочернюю таблицу - ничего. Позднее специальные операции начинают заполнять дочернюю таблицу строками, которые соответствуют строкам в родительской таблице, но в случайном порядке. Проблема заключается в том, что это приведет к разбивке страниц на вставках, фрагментации индекса и эффекту «швейцарского сыра» для удалений. Я признаю, что это не те термины, с которыми я хорошо знаком, и при поиске в них хиты, похоже, связаны с Microsoft SQL сервером. Являются ли эти проблемы, характерные для MS (то есть, анализирует ли PG и подобные вопросы проблему PG)? Если это так, то это еще одна причина использовать базу данных, такую ​​как Postgresql.

Answer 1

Если это строгое отношение 1-1, я не вижу причин, чтобы не использовать первый вариант.

Второй вариант обеспечивает некоторую гибкость, позволяя сделать его отношением 1-много позже, хотя, вероятно, именно поэтому администраторы могут предпочесть этот вариант.

Answer 2

Во-первых, если у вас есть отношение 1: 1, нет проблем с первичным ключом таблицы, также представляющим внешний ключ для другой таблицы, и на самом деле я бы предположил, что это предпочтительный подход.

Во-вторых, при любом отношении 1: 1 первый вопрос, очевидно, должен заключаться в том, требуется ли это отношение, поскольку обычно вы можете просто включить столбцы дочерней таблицы в основную таблицу. Тем не менее, бывают случаи, когда соотношение 1: 1, очевидно, имеет смысл.