Если Б - это все объекты, а А - часть (активная или какая другая) , то логичней иметь ФК в обратном направлении из А в Б.

CelticsТаблица А - набор записей (1, 2, 3) с полями (a, b, c), где 1, 2, 3 - объекты, a, b, c - свойства объектов
Набор записей Б (еще не таблица) - нужно правильно связать с таблицей А.
Дык если она не часть БД, то причем здесь "связывание" по ФК. И что есть отдельно или не отдельно - где это все происходит - то? Celtics

Набор записей Б (1, 2, 3, 4, 5) с полями (d, e, f, g), где 1, 2, 3, 4, 5 - объекты, d, e, f, g - свойства объектов

Из них, например, записи(объекты) 1, 4 в Б - мертвые. Они уже не меняются. 2, 3, 5 - связываются с таблицей А и их поля меняют значения.

Для простоты представте, что были две таблицы А и Б, связаны один к одному. А<-Б. А потом из А начали удалять записи. Как поступить в тслучае если в Б остались мертвые записи, выносить их отдельно либо прибивать внешний ключ? 1, 2, 3, 4, 5 - значения ПК в обоих таблицах? Тогда не понял про прибивать.

Celtics1, 2, 3, 4, 5 - объекты. Их поля c, d, e, f описаны в таблице Б. Еще там есть ПК и FK.Скажите, если отношение 1 к 1 , то зачем два поля? CelticsО FK и идет речь. Он уникален и указывает на запись из А. Если прибить записи в А, то его нужно либо отключить, либо вынести соответствующие записи в отдельную таблицу.Либо выбросить поле ФК.

Кажется, мы про разные поля. Как я понял, есть аналог следующего:

А( ID:ПК, a, b, c)
Б( ID:ПК, ID2:FK, d, e, f, g)

Мой вариант:

А( ID:ПК:FK, a, b, c)
Б( ID:ПК, d, e, f, g)