Related link: http://conferences.oreillynet.com/os2002
Databases are the big topic all over the
O’Reilly Open Source Convention.
It’s no surprise that the room would fill up (particularly because it
was on the small side) for the tutorial on
ACID Transactions in MySQL with InnoDB.
Interest runs high concerning the features being added gradually over
the past couple years by MySQL AB to bring MySQL in line with more
heavyweight databases, and transactions is what comes first to
mind. (Another biggie, foreign keys, is offered by the same InnoDB
type that supports transactions.) Furthermore, the talk was given by
some of the leading members of the team, David Axmark and Kaj
S. Ärno, with Monty Widenius chiming in with comments from
time to time.
The pattern was like old blues men performing. David or Kaj would
offer a standard explanation of what goes on, and the thin, wry voice
of Monty would then riff cynically from the rear. Nothing is as simple
as the textbooks would have you believe. Concerns for consistency in
the field of databases spawn concepts that range from the complicated
to the truly spooky, such as phantom reads. And even when you’ve
accounted for the four types of consistency (as David and Kaj did in
their slides and presentation) little anomalies intrude. These were
the contributions Monty made.
While I would like the interruptions and discussions to be planned a
little better, I really thought it was important to hear both sides of
the talk. We need to understand the concepts in a clean, structured
presentation as the folks at the front gave us. And Monty’s
off-the-cuff observations were marvelously educational too. They show
that relational databases are subtle treasures that require skillful
handling, and that there is no end to learning about them.
A similar pattern emerged across the hall where a key developer of
PostgreSQL, Bruce Momjian, offered his expertise on
PostgreSQL Performance Tuning. Here again, the official
presentation gave way regularly to discussions among Momjian, team
members, and the audience regarding what worked, what was useless or
obsolete, and what had to be better integrated with operating systems
or gain a better interface. While these cadenzas and obbligatos could
have been considered confusing, they showed that databases are always
evolving. It’s a sign of strength that chief developers re-examine
basic issues again and again.
Relational databases are still the stars of the data storage
firmament. After them, the next most popular type of databases are the
even older DBM key/value type. These old stand-bys have been
challenged by companies pushing object-oriented databases, and
recently XML databases have emerged with claims on the future.
Why haven’t the challengers won out? Perhaps it’s because
object-oriented and XML solutions demand that the organization data be
limited for the convenience of the programming language. Organizations
that invest huge sums into collecting data want all the richness and
sophistication they can get in searching that data, and the best we
have at this point is still the relational database. So we’re going to
have to deal for some time to come with painful clashes between the
relational model and the model offered by whatever language we choose
to work in.
This theme also motivated a third talk I attended,
Integrating Databases with Zope.
While there was plenty of Zope in the talk, the underlying concept was
to maintain data in its relational format as much as possible, rather
than creating a competing form of storage, while still cataloging and
presenting the most important data in convenient user displays.
I also had a bit of fun trying out a decidedly old-fashioned
technology, sailing. Although I did little more than tie the fender, I
enjoyed the wonderful trip through San Diego bay and the sight of the
full moon at night over the lit-up skyscrapers of downtown. A little
more light would have been advisable for our boat, whose lights
malfunctioned. So we motored back as fast as could in the dark,
holding a tiny pocket flash out to avoid a collision from which no hash function could rescue us.