Законный? Два внешних ключа, ссылающиеся на тот же первичный ключ

Ваш проект нарушает Третью нормальную форму , если Network.Owners_PersonID хранится в сети с избыточностью.

Но я не понимаю, как на самом деле помогает дизайн DBA. Я ожидал, что Друзья будут таблицей «многие-ко-многим» между пользователями и Сетями :

CREATE TABLE tblUsers (
  PersonID INT IDENTITY PRIMARY KEY
);

CREATE TABLE tblNetworks (
  NetworkID INT IDENTITY PRIMARY KEY,
  Owner_PersonID INT NOT NULL REFERENCES tblUsers
);

CREATE TABLE tblFriends (
  NetworkID INT NOT NULL REFERENCES tblNetworks,
  FriendID INT NOT NULL REFERENCES tblUsers,
  PRIMARY KEY(NetworkID, FriendID)
);

Другими словами, у вас есть простая таблица «многие-ко-многим». отношение ко многим:

Users ----<- Friends ->---- Networks

И, кроме того, Networks ссылается на Users только для идентификации владельца данной сети. Таким образом, для данной сети есть только одна строка, поэтому вы не можете создать аномалию обновления, изменив владельца сети в некоторых строках.

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

SELECT ... FROM Networks n JOIN Friends f ON (n.NetworkID=f.NetworkID)

Таким способом можно получить всех друзей пользователя из всех сетей (передайте идентификатор данного пользователя в параметре ? ):

SELECT ... FROM Friends u 
JOIN Friends f ON (u.NetworkID=f.NetworkID)
WHERE u.UserID = ?

В вашем первоначальном дизайне это почти то же самое:

SELECT ... FROM Networks u
JOIN Networks f ON (u.Owner_UserID=f.Owner_UserID)
WHERE u.FriendID = ?

Но преимущество в том, что вы устранили возможную аномалию обновления.

Я хочу создать вторую таблицу, tblNetwork, которая будет содержать все отношения между пользователями с (NetworkID int identity {{ 1}} PK, Owners_PersonID int FK, Friends_PersonID int FK и т. Д.). Или, наоборот, удалите NetworkID и укажите как Owners_PersonID, так и Friends_PersonID в качестве основного ключа .

Я не вижу в этом никаких проблем. И я согласен с тем, что NetworkID является лишним - два FK являются естественным ключом для таблицы, и поэтому вы должны просто использовать их в качестве первичного ключа, если у вас нет причин производительности, по которым вам нужно ссылаться к конкретным отношениям по суррогатному идентификатору (которого у вас, похоже, нет в данном случае).

Я говорю, делайте это по-своему. Наличие этой третьей таблицы усложняет программирование.

Если я вас правильно понимаю, вы предлагаете:

Person              PersonID PK
FriendList          FriendListID, OwnerID, PersonID 

DBA предлагает:

Person              PersonID PK
FriendList          FriendListID, OwnerID
FriendListEntry     FriendListID, PersonID

Ваш подход потребует нескольких строк для каждый друг в списке. Это будет повторять OwnerID несколько раз, нарушая нормальную форму. Решение DBA более нормализовано, имея только значения, зависящие от FriendListID в таблице FriendList.

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

Единственная схема, которая имеет для меня смысл, такова:

Person
    PersonID Int PK

Friend
    PersonID Int PK FK
    OtherPersonID Int PK FK

Итак, у вас может быть процедура под названием FriendList , которая выполняет этот красивый чистый запрос:

Select Person.*
From Friend
    Inner Join Person On Friend.OtherPersonID = Person.PersonID
Where Friend.PersonID = @PersonID;

Я не одобряю выбор всех столбцов.