The iBATIS philosophy - iBATIS in Action - page 28

transactional systems, batch systems, and reporting systems. This means that
regardless of what systems are accessing a given database, i BATIS is a great tool.
Second, if you are able to use i BATIS , or even a consistent platform like Java, then
you can use distributed caches to communicate among different systems. Finally,
in the most complex of cases, you can easily disable i BATIS caching and write spe-
cific queries and update statements that behave perfectly, even when other sys-
tems using the same database do not.

1.4.3 Complex keys and relationships

Relational databases were designed and intended to follow a set of strict design
rules. Sometimes these rules are broken, perhaps for a good reason, or perhaps
not. Complex keys and relationships are usually the result of a rule being broken,
misinterpreted, or possibly even overused. One of the relational design rules
requires that each row of data be uniquely identified by a primary key. The sim-
plest database designs will use a meaningless key as the primary key. However,
some database designs might use what is called a natural key, in which case a part
of the real data is used as the key. Still more complex designs will use a composite
key of two or more columns. Primary keys are also often used to create relation-
ships between other tables. So any complex or erroneous primary key definitions
will propagate problems to the relationships between the other tables as well.
Sometimes the primary key rule is not followed. That is, sometimes data
doesn't have a primary key at all. This complicates database queries a great deal as
it becomes difficult to uniquely identify data. It makes creating relationships
between tables difficult and messy at best. It also has a performance impact on the
database in that the primary key usually provides a performance-enhancing index
and is also used to determine the physical order of the data.
In other cases, the primary key rule might be overdone. A database might use
composite natural keys for no practical reason. Instead the design was the result of
taking the rule too seriously and implementing it in the strictest sense possible. Cre-
ating relationships between tables that use natural keys will actually create some
duplication of real data, which is always a bad thing for database maintainability.
Composite keys also create more redundancy when used as relationships, as multi-
ple columns must be carried over to the related table to uniquely identify a single
row. In these cases flexibility is lost because both natural keys and composite keys
are much more difficult to maintain and can cause data-migration nightmares.
i BATIS can deal with any kind of complex key definition and relationship.
Although it is always best to design the database properly, i BATIS can deal with
tables with meaningless keys, natural keys, composite keys, or even no keys at all.