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

Funnily enough I learnt about the existence of blackholes today too.

Arguably the question here is actually a broader one i.e. whether or not business logic should be embedded in database triggers or not. In this instance the blackhole table is essentially being used as a transient data store that the trigger on the blackhole table can make use of. Should the trigger be used in the first place? To me that is the real meat of the question.

Personally I feel that the use of triggers should be restricted to logging and DBA-specific tasks only and should not contain business logic (or any logic for that matter) that should belong firmly in the application layer. It appears as though there have been quite a few opinions expressed about whether database triggers are evil or not. I think your question kinda falls into that category too.

Embedding application layer logic in database triggers can be risky.

It is likely to end up splitting business logic between application code and the database. This can be very confusing indeed for somebody trying to support and get their head into a code base.

If you end up with too much logic in triggers, and indeed stored procedures, you can easily end up with performance issues on your database server that could have, indeed should have been addressed by distributing the heavy duty processing tasks i.e. complex business logic among application servers and leaving the database server free for its primary purpose i.e. serving data.

Just my two bits' worth of course!