At the time of writing, I'm currently over the Atlantic, on my way from London to San Francisco, which is probably a good thing as it means my neck is decisively out of the reach of some previous developers I've worked with.
Let me clear this up for you; your database isn't a message queuing system. You don't use it schedule jobs or queue up tasks to be completed. If you need something to do that, use a queuing system. Your database is for data...the clue is in the name; don't shove temporary messages in there.
There are many reasons why this is a bad idea. One major issue is the fact that in databases there is no real way to not enforce a policy by which you can guarantee that a double-read will not occur, and that is by utilizing row locks. This in turn, results in processes (either incoming out outgoing) being blocked, which in turn results in processing only being able to be done in a serial fashion.
Furthermore, in order to check if there is any work to do you end up essentially...