title: JPA/Hibernate and composite keys
body: <p>I have come across some <strong>SO</strong> discussions and others posts (e.g. <a href="https://stackoverflow.com/questions/4024800/jpa-hibernate-whats-better-for-composite-primary-keys-idclass-or-embeddedid">here</a>, <a href="http://www.ibm.com/developerworks/java/library/os-hibernatejpa/" rel="nofollow noreferrer">here</a> and <a href="http://www.coderanch.com/t/486475/ORM/databases/JPA-composite-primary-key-classes" rel="nofollow noreferrer">here</a>) where using composite primary keys with <strong>JPA</strong> is described either as something to be avoided if possible, or as a necessity due to legacy databases or as having "hairy" corner cases. Since we are designing a new database from scratch and don't have any legacy issues to consider is it recommended or let's say, safer, to avoid composite primary keys with <strong>JPA</strong> (either <strong>Hibernate</strong> or <strong>EclipseLink</strong>?). </p>
  
  <p>My own feeling is that since <strong>JPA</strong> engines are complex enough and certainly, like all software, not without bugs, it may be best to suffer non-normalized tables than to endure the horror of running against a bug related to composite primary keys (the rationale being that numeric single-column primary keys and foreign keys are the simplest use case for JPA engines to support and so it should be as bug-free as possible).</p>