Is a 'blackhole' table evil?

Question

Reading to this question i\'ve just learned the existence of the blackhole table trick: basically consist in using a single table to insert data, and then a tri

Answer 1

The original question that prompted yours does not get at the heart of MySQL's "blackholes."

What is a BLACKHOLE?

In MySQL-speak, BLACKHOLE is a storage engine that simply discards all data INSERTed into it, analogous to a null device. There are a number of reasons to use this backend, but they tend to be a bit abstruse:

• A "relay-only" binlog-filtering slave
  See the docs, and here and here.
• Benchmarking
  E.g., measuring the overhead of binary logging without worrying about storage engine overhead
• Various computational tricks
  See here.

If you don't know why you need a data sink masquerading as a table, don't use it.

What is the technique you are asking about?

The use under consideration seems to be to:

1. redirect INSERTed data to other tables
2. audit log the original INSERTion action
3. discard the original INSERT data

Thus the answer to the question of "evilness" or pros/cons is the same as the answer to those questions for insertable/updatable VIEWs (the common way to implement #1), trigger-based audit logging (how most people do #2) and behavioral overrides/counteractions generally (there are a number of ways to accomplish #3).

So, what is the answer?

The answer is, of course, "sometimes these techniques are appropriate and sometimes not." :) Do you know why you're doing it? Is the application a better place for this functionality? Is the abstraction too brittle, too leaky, too rigid, etc.?