Лучший первичный ключ для таблицы дружбы - PullRequest
0 голосов
/ 05 мая 2010

Я прочитал несколько решений для таблицы дружбы в MySQL и выбрал довольно простую таблицу с двумя полями user_a и user_b. Затем я бы использовал запрос с UNION, чтобы получить список всех друзей пользователей (как они могут быть в user_a или user_b). Мой вопрос сейчас ... лучше ли иметь автоматически увеличивающийся уникальный идентификатор или составной идентификатор?

Таблица 1)

user_a, user_b

Таблица 2)

unique_id, user_a, user_b

Ответы [ 2 ]

1 голос
/ 05 мая 2010

Мои комментарии:

  • любой подход к ключу подойдет. Я бы предпочел compound key вместо surrogate key, чтобы сэкономить место и избежать дополнительных индексов
  • может потребоваться суррогатный ключ - некоторые DAL не работают с составными ключами

Обновление:

Вы можете считать, что дружба - это улица с двусторонним движением. То, что UserA подружился с UserB, не означает, что UserB подружился с UserA. Если вы отслеживаете обе стороны, это облегчает ваши запросы. В этом случае вы делаете:

Friend
-------
UserID
FriendUserID

Итак, вы совпадаете только по столбцу UserID, чтобы получить список друзей пользователя. Если два пользователя дружат друг с другом, вы помещаете в таблицу две строки. Если один пользователь лишает друзей другого, вы удаляете эту строку.

0 голосов
/ 05 мая 2010

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

Если на дружбу ссылаются в другом месте, в долгосрочной перспективе это сэкономит больше места, чтобы иметь один числовой идентификатор в качестве внешнего ключа в таблице ссылок, чем составной идентификатор. Кроме того, индекс по одному идентификатору будет (немного) короче и быстрее, чем составной индекс, если вы часто запрашиваете идентификатор дружбы.

...