Advocating simple key definitions

exercise No. 4

Q:

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

@Entity
public class Airline {
   @Id
   @GeneratedValue(strategy=GenerationType.IDENTITY)
   Long id;
   
   @Column(unique=true, nullable=false)
   String name;

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

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

A:
Pros:

  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.

Cons:

  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`)
...
Prev  Up  Next
Adding keys and AUTO_INCREMENT  Home  List of Exercises