In the conclusion, the author mentions the number of db objects required to support auditing in the two latter methods (900 and 450, respectively for a 150-table db). The implication seems to be that fewer objects = better (performance? maintenance?).

This kind of thinking, however, usually leads to bad db design... "fewer tables must be better, so let's use a single 'lookup' table for all our codes", or "let's denormalize so we don't have to do all those joins".

When making design decisions, be sure you know exactly the performance metrics you're making tradeoffs for. "Number of db objects" should be at or near the bottom of any such list.

TroyK