ejb3: отображение таблицы соединений «многие ко многим» с простым первичным ключом

Question

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

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

Поскольку книги всегда используют подход составных ключей, я хотел бы знать, есть ли какие-либо негативные последствия, если я использую простой один столбецсуррогатные ключи для JoinTable?

Answer 1

Я стараюсь полностью избегать составных ключей.

А?Зачем?Я имею в виду, почему полностью избегая их?В чем причина этого?

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

Без обид, но тогда у нас нет такого же определения простоты.Я действительно не вижу, где это проще.

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

Прежде всего, не используйте SELECT для проверки уникальности (вы можете иметь условие гонки, SELECTбез блокировки всей таблицы ничего не будет гарантировано), используйте ограничение UNIQUE, вот для чего предназначен UNIQUE.

И давайте представим одну секунду, что SELECT был бы возможен, вы действительно находите это проще?В общем, люди стараются избегать попадания в базу данных, если это возможно.Они также избегают необходимости выполнять дополнительную работу.

Поскольку в книгах всегда используется подход составных ключей, я хотел бы знать, есть ли какие-либо негативные последствия, если я использую простые суррогатные ключи с одним столбцом для JoinTable?

Итак, вы имеете в виду что-то вроде этого:

   A              A_B                 B
-------      ------------------    --------
ID (PK)      ID (PK),              ID (PK)
             A_ID (FK),
             B_ID (FK),
             UNIQUE(A_ID, B_ID)   

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

1. Приведенный выше дизайн просто не является стандартным способом отображения отношения (m: n), это не то, что люди привыкли находить.
2. A_B на самом деле не является сущностью сама по себе (что так или иначе предлагает модель, см. # 1).
   • Пара (A_ID, B_ID) является естественным кандидатом на ключ, почему бы не использовать его (и тратить место)?
   • Вышеприведенный дизайн не проще,это вносит больше сложности.

Подводя итог, я не вижу никакого преимущества.

Answer 2

На мой взгляд, использование одного первичного ключа - плохая идея.

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

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