В соединительной таблице, если мне нужен уникальный уникальный идентификатор и отдельный уникальный составной идентификатор, какой должен быть первичный ключ?

Question

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

У меня есть:

Таблица APPLICATION - содержит информацию о типе приложения

- APPLICATION_ID NUMBER(38) PK

Таблица RESPONDENT - содержит информацию о пользователе

- RESPONDENT_ID NUMBER(38) PK

Таблица соединений APPLICATION_INSTANCE - содержит информацию о конкретном пользователе, заполняющем конкретную заявку

- APPLICATION_INSTANCE_ID NUMBER(38) unique (PK?)
- APPLICATION_ID NUMBER(38) FK (PFK?)
- RESPONDENT_ID NUMBER(38) FK (PFK?)

Варианты использования:

1. A respondent can only fill out one application of each type
2. APPLICATION_INSTANCE also holds information like the status of an application and date submitted
3. Must be able to query knowing only the APPLICATION_INSTANCE_ID
4. MUST be able to find all applications of a given application type efficiently
5. MUST be able to find all applications of a given respondent efficiently

Я вижу два варианта (я склоняюсь к первому):

1. make APPLICATION_INSTANCE_ID PK and enforce a unique constraint between APPLICATION_ID and RESPONDENT_ID 
2. make APPLICATION_ID and RESPONDENT_ID a composite PK and make a unique index on APPLICATION_INSTANCE_ID 

Какой вариант дает лучшую производительность (скорость запроса), когда? Есть ли существенная разница? Есть ли лучший способ?

Answer 1

В общем, я бы сделал первичный ключ single идентификатором и объявил бы пару уникальной.

Соединительная таблица может представлять как объект, так и отношение.Например, «покупка» - это таблица соединений, которая может объединять «клиента» и «продукт», но иметь свои собственные атрибуты.

Когда вы описываете это, у вас есть такая сущность.У сущности есть два действительно важных атрибута (приложение и респондент).Эти атрибуты имеют действительно важное свойство (они совместно уникальны), поэтому они должны быть объявлены unique.

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

Из того, что вы описываете, я бы предложил:

• Первичный ключ: application_instance_id
• Уникальный: (respondent_id, application_id)
• Индекс: (application_id)

Третий индекс может не потребоваться, поскольку Oracle поддерживает пропуски в индексах.Возможно, вы захотите проверить, приемлема ли производительность без индекса.