<parameter property="postalCode" jdbcType="VARCHAR" />
<parameter property="country" jdbcType="VARCHAR" />
<parameter property="version" jdbcType="NUMBER" />
insert into account (
city, state, postalCode,
) values (
While that does not look any less verbose than the inline version, the difference
becomes more apparent when you start including additional statements. Not only
will they be simplified (because you do not need to specify the types for each
property), but the centralized maintenance also means that when you make
changes to the parameter map, you only have to do it once.
For example, everywhere that the memberSince property is passed in, it is auto-
matically handled as a TIMESTAMP database type. If later, we decide that DATE is
adequate (because we do not need to know the number of seconds since an
account was created), we do it in exactly one place—the parameter map.
Another added benefit to this approach is that the inline parameter map does
not need to be generated dynamically when first called.
In both of the previous examples, the code to call the statements is identical
(except for the name of the mapped statement in our example):
The difference between inline and explicit parameter maps is maintenance cost
and performance—both are improved by using externally defined parameter maps.
With any database, the ability to uniquely identify a row in a table is absolutely crit-
ical. Nearly all databases include the means to automatically generate primary key
values for newly inserted rows. While this is convenient, it can be problematic