Advocating simple key definitions

exercise No. 3


We might choose a simpler model to achieve non-nullable keys:

public class Airline {
   Long id;
   @Column(unique=true, nullable=false)
   String name;

   @Column(unique=true, nullable=false)
   String icaoCode;
   public Airline(final String name, final String icaoCode) { = name;
      this.icaoCode = icaoCode;
   protected Airline(){}   

Discuss the pros and cons of this approach compared to our previous exercise.


  1. This approach is easier to understand.

  2. Stable approach with respect to Java code refactoring: If e.g. the icaoCode property gets consistently renamed to icaoCodeNumber SQL - DDL code will still be generated properly. However our complex solution may overcome this problem by providing stable SQL - DDL attribute names via @Column(name="icaoCode" ...) thereby protecting the database from unnecessary schema evolution issues being inflicted by Java code refactoring.

  1. Does not work for composed keys.

  2. Does not allow for self explanatory constraint names. We end up with e.g. :

      UNIQUE KEY `UK_s759kv0st7r42c85xqjjiusde` (`icaoCode`),
      UNIQUE KEY `UK_swdntm8xd26ugm3t78mkkted2` (`name`)