отдельные столбцы для отдельных полей идентификатора?

Question

Скажем, у нас есть таблицы A, B и C, а затем мы хотим, чтобы таблица Z содержала столбец TYPE, который сообщает нам, с какой таблицей A, B и C связана запись в Z.

Лучше ли иметь отдельный столбец для каждой таблицы, например столбцы A_ID, B_ID и C_ID, чтобы использовать индексирование?

Или есть какая-то причина, по которой следует использовать общий столбец TYPE_ID может быть лучше с точки зрения производительности?

Answer 1

Иногда это запах кода схемы.

Если вы планируете поместить это как один столбец в Z, означает ли это, что только один из A, B, C может быть применим к Z?

Прежде чем принять решение, я бы действительно сказал, что мне нужно больше узнать о сущности и модели использования. Доступ поступает из известных A, B или C, или дополнительная информация ведется со стороны Z? Если он управляется со стороны Z, хотите ли вы получить все столбцы A, B и C и затем использовать их выборочно из приложения, или просто Zs с As или Zs с Bs, т.е. вы обычно знаете подтип? Кроме того, у A, B и C должно быть достаточно столбцов, чтобы заслужить разделение строки Zs, если они равны 1-1 (т. Е. Вы можете иметь столбцы в Z и просто NULL)

Просто для полноты, другая возможность, которая дает вам больше ссылочной целостности (потому что с одним столбцом вы не можете быть FK для одной из трех таблиц), это иметь таблицы Z_A, Z_B, Z_C:

со схемами:

Z_A:
Z_ID REFERENCES (Z.ID)
A_ID REFERENCES (A.ID)

Z_B:
Z_ID REFERENCES (Z.ID)
B_ID REFERENCES (B.ID)

Z_C:
Z_ID REFERENCES (Z.ID)
C_ID REFERENCES (C.ID)

Поскольку все идентификаторы уникальны в каждой таблице, это довольно красиво ограничивает все, за исключением того, что нет ничего декларативного, чтобы не допустить, чтобы Z лежал в нескольких таблицах без триггера (нельзя создать уникальное ограничение для индексированного представления над UNION ALL в SQL Server ).

Хотя кажется, что количество таблиц умножается, их обычно можно свернуть в представления.

Answer 2

Использование type_id, а затем fk_id не будет хорошо, потому что селективность по индексу составляет 33%, что слишком высоко для какой-либо пользы. Вместо этого вы всегда будете индексировать fk_id (который ссылается на A, B, C) - что может потребовать разрыва связи между 3 значениями (если идентификатор используется всеми 3 типами).

При хранении индекс никогда не хранит нулевые значения, поэтому абсолютное количество элементов, хранящихся в индексах, будь то одно (fk_id) или многократное (a_id, b_id, c_id), будет одинаковым.

Если вы входите с точным fk_id (из A, B, C), то использование уникального индекса для (fk_id, type_id) в этом порядке может быстро определить требуемую запись.

Казалось бы, для простоты и краткости два столбца здесь лучше, чем 3.