title: Is the domain model/JPA entity model supposed to create a well-designed database table structure?
body: <p>Let's assume the domain model of an application that is supposed to be built from scratch is described as follows:</p>
  
  <p>A Person might live at an address. A Person can own multiple cars.</p>
  
  <p>If I had to design the database first, I would probably come up with the following database design (normalization, cascading, etc. are not supposed to play a major role for my concrete question).</p>
  
  <pre><code>Person (id, name)
  Address (id, street, zip, city, person_id)
  Car (id, manufacturer, yearBuilt, color, person_id)
  </code></pre>
  
  <p>I have mainly followed standard design concepts (e.g. described in this link <a href="http://db.grussell.org/section006.html" rel="nofollow">http://db.grussell.org/section006.html</a>).</p>
  
  <p>As you can see the address table has a foreign key to the person table as the person - address relationship can be considered optional.</p>
  
  <p>The fact that a person can own multiple cars is implemented by putting a foreign key to a person in the car table. I think this is the standard way of modelling 1..m relationships.</p>
  
  <p>If I had to design the domain model first, I would probably come up with the following design:</p>
  
  <pre><code>public class Person {
  
      private String name;
      private Address address;
      private List&lt;Car&gt; cars;
  
      // Getters and setters
  }
  
  public class Address {
  
      private String street;
      private String zip;
      private String city;
  
      // Getters and setters
  }
  
  public class Car {
  
      private String color;
      private Date yearBuilt;
  
      // Getters and setters
  }   
  </code></pre>
  
  <p>In that domain model, the <code>Person</code> class has all necessary relationships. The <code>Address</code> and <code>Car</code> classes do not need to know anything about their owning <code>Person</code>. </p>
  
  <p>I could now turn these classes into JPA entities by adding <code>@Entity</code> and providing an <code>@Id</code> attribute for every class. </p>
  
  <pre><code>@Entity
  public class Person implements Serializable {
  
      @Id
      private Long id;
      private String name;
      @OneToOne
      private Address address;
      @OneToMany
      private List&lt;Car&gt; cars;
  
      public Person() { }
  
      // Getters and setters
  }
  
  @Entity
  class Address implements Serializable {
  
      @Id
      private Long id;
      private String street;
      private String zip;
      private String city;
  
      public Address() { }
  
      // Getters and setters
  }
  
  @Entity
  class Car implements Serializable {
  
      @Id
      private Long id;
      private String color;
      private Date yearBuilt;
  
      public Car() { }
  
      // Getters and setters
  }
  </code></pre>
  
  <p>If my JPA provider creates the tables according to the provided annotations, the following database structure is created:</p>
  
  <pre><code>Person (id, name, address_id)
  Address (id, street, zip, city)
  Car (id, manufacturer, yearBuilt, color)
  Person_Car (person_id, car_id)
  </code></pre>
  
  <p>As you can see, that does not correspond to the database structure I would create if I had to design the database first. I see a few flaws in the database model created by the JPA provider:</p>
  
  <ol>
  <li>As the person - address relationship is optional, I would have put the foreign key to a Person into the Address table and not vice versa.</li>
  <li>As the standard way of modelling a 1..m relationship is to put the foreign key of the owning class into the detail class, I would have never come up with a relation or association table. Why would I want to have that if the relation is not described by additional attributes?</li>
  <li>To join a Person to a Car, the JPA provider needs to perform an additional join to the relation or association table. Does this measurably decrease the performance?</li>
  </ol>
  
  <p>What I could do now is to provide the JPA entity classes with additional fields and/or annotations to strive for the database structure one might expect. </p>
  
  <p>Is it desirable to strive for a domain model/JPA entity design that is able to create an expected database structure (as if database-first-approach was used)? If so, is it acceptable to have a domain model that is different from a domain model one would create intuitively? What are the advantages in designing a domain model/JPA entity model that will create some sort of "best practice" database structure?</p>