The points that we want you to take away from this lab are:

• Object-relational impedance mismatch is something that we have to deal with when using object-oriented languages with relational databases.

  Other forms of programming languages have similar difficulties when interacting with relational databases --- it is not just object-oriented languages that have an impedance mismatch.

  In practice it means that we have a lot of plumbing code to write. Pull the data out of an object and put it in a JDBC/JDBI statement. Pull the data out of a result set and put it in an object.
  Sometimes it means that we need to do some additional massaging of the data to convert it from the form that the database is using into the form that the object is using, and vice-versa.
  Object-oriented languages use object associations to link related objects. Relational databases use common attributes to link related rows.

• There are low-level database access APIs like JDBC that are very flexible, but require the programmer to write a lot of plumbing code.

• There are higer-level database access APIs like JDBI that require a lot less plumbing code, but require your system to have field and column names that are consistent between the application and the database.

• There are even higher-level database access APIs called ORMs (Object Relational Mapping APIs) that we haven't discussed in this lab, but it is worth pointing out now. These APIs try to hide the impedance mismatch from the programmer. From the programmer's perpective, they allow the application to save an object directly in the database. That is not what actually happens --- the impedance mismatch is still there --- it is just that the ORM does the work of mapping the data between the two models (the programmer will need to tell it how to do this). ORMs can be quite tricky to use --- you really need to know what you are doing when working with one of these.

  An API like JDBI is a nice middle ground --- easy to use, flexible, and does a fair amount of the work for you.

• If we have been using standard features of SQL then we should be able to switch between DBMSs without too much drama.

  Why would we want to do this?

  It is common to use an embedded database for testing and continuous integration. H2 is fantastic in this role. In production mode, a more heavy-duty DBMS like PostgreSQL is used.
  We may have trouble with a particular DBMS, or DBMS vendor that requires us to switch.
  We would also need to migrate the data --- that is a whole other can of worms.