Hi, just a voice from the trenches, having done this a few times and
made some mistakes:
Do not invent a new kind of database for the change log. Instead use the
one you already have
for entries, with some appropriate indexing enhancements to support the
change log semantics required.
i.e. each change log record is in fact an entry. (there may be a way to
do it where the change log
data is actually stored in the entries themselves, and absolutely no
additional records are
required, but this seems to take an extra high level of cunning to pull
off).
But, please don't make work for yourself by doubling the kinds of
database you have.
Two databases also makes it hard to ensure transactional integrity
between the main
db and the change log (which is important to have).
