FK / PK и FK null Вопрос

Question

Я разрабатываю несколько таблиц для своего сайта с пользовательским контентом, и я теряюсь в концепции FK для этой ситуации.Чем отличаются эти два случая:

Случай A:
Таблица друзей
user_id (FK)
friend_id (FK)

CaseB:
Таблица друзей
id (PK)
user_id (FK)
friend_id (FK)

Я пытаюсь понять, что одна таблица имеет2 ФК и 1 имеет 2 ФКС + 1 ПК.Большинство схем, которые я видел для друзей, имеют вариант А, в котором всего 2 FK и нет ПК.Но большинство других таблиц, которые я вижу, имеют случай B PK.Так в чем же разница / преимущество / недостаток в обеих таблицах и какой из них использовать?

---

Второй вопрос, который у меня возник, заключается в том, если у меня есть PK в таблице A и я использую его как FK в таблице B, должно ли оно быть NOT NULL в таблице B или оно может быть NULL, даже если в таблице A наличие PK должно быть NOT NULL?Примером этого является отображение города и штата.Состояние в таблице состояний требуется как NOT NULL.В таблице городов я сохраняю все значения как NOT NULL DEFAULT 0, поскольку у городов нет состояний (городов мира), но я не хочу хранить NULL в db, поэтому я пишу 0 для всех нулевых значений только для того, чтобы держать ячейки занятыми.

Answer 1

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

Возможно, что в A первичный ключ на самом деле является составным ключом: (user_id, friend_id). В этом случае разница между этими двумя альтернативами состоит в том, что A не допускает дублирования комбинаций пользователя и друга, тогда как B допускает эти дубликаты. Это существенная разница.

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

Answer 2

В случае A, хотя user_id и friend_id являются FK, они, скорее всего, являются составным первичным ключом.В случае B есть отдельный PK (id) для идентификации каждой уникальной дружбы.Оба они фактически делают одно и то же, но, по моему мнению, id во 2-м случае является избыточным, так как PK (user_id, friend_id) может действовать вместе, чтобы стать составным первичным ключом, который будет уникально идентифицировать каждую дружбу.Предлагаю вам прочитать хорошую книгу по нормализации:)

Answer 3

Рекомендуется случай A.

Случай B часто используется, когда вам нужно перенести длинный составной ключ в другую таблицу.Например, скажем, нам нужно создать отношение «многие ко многим» (T3) между таблицами T1 и T2.

Case A (natural keys):
table T1(pk1, pk2, pk3, pk4, someValue)
table T2(pka, pkb, pkc, pkd, otherValue)
table T3(pk1, pk2, pk3, pk4, pka, pkb, pkc, pkd, create_date)

Требуются три уникальных индекса (по одному в каждой таблице).Запрос T3 легко выполнить.

Case B (surrogate keys):
table T1(t1_id, pk1, pk2, pk3, pk4, someValue)
table T2(t2_id, pka, pkb, pkc, pkd, otherValue)
table T3(t1_id, t2_id, create_date)

Требуются пять уникальных индексов.Те же три, что и в случае А, плюс один для каждого суррогатного ключа.T3 теперь становится намного меньше, но за счет того, что он больше не может запрашивать отношения M: M, не присоединяясь ни к T1, ни к T2.Это может или не может иметь большого значения для любого типичного приложения.

Я думаю, что это в значительной степени подводит итог.