Кажется, что только поддержка 2-го класса для составных ключей базы данных в Java JPA (через аннотации EmbeddedId или IdClass). И когда я читаю составные клавиши, независимо от языка, люди продолжают сталкиваться с тем, что они плохо работают. Но я не понимаю, почему. Сложные ключи все еще приемлемы для использования в эти дни? Если нет, почему бы и нет?
Я нашел одного человека, который согласен со мной: http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx
Но другой, кто этого не делает: http://weblogs.java.net/blog/bleonard/archive/2006/11/using_composite.html
Является ли это только мной, или люди не могут отличить, где подходящий составной ключ или нет? Я вижу составные первичные ключи полезными, когда таблица не представляет собой сущность - т.е. Когда она представляет таблицу соединений.
Простой пример:
Actor { Id, Name, Email }
Movie { Id, Name, Year }
Character { Id, Name }
Role { Actor, Movie, Character }
Здесь актер, фильм и персонаж явно выигрывают от наличия столбца Id в качестве первичного ключа.
Но роль - это таблица соединений "Множество ко многим". Я не вижу смысла создавать идентификатор, чтобы идентифицировать строку в базе данных. Мне кажется очевидным, что первичный ключ { Actor, Movie, Character }. Это также кажется довольно ограниченной функцией, особенно если данные в таблице соединений постоянно меняются, вы можете столкнуться с первичными коллизиями после того, как первичная последовательность ключей обернется вокруг 0.
Итак, вернемся к исходному вопросу, все же приемлемой практикой является использование составных первичных ключей? Если нет, почему бы и нет?
