The automated way of doing so is by defining foreign keys on your tables, with a DELETE CASCADE
in your case. This way, a DELETE
on the master table will propagate and delete matching rows from all derived tables.
You will have to use InnoDB
tables for that.
I assume your tables do not have foreign keys at the moment, otherwise you wouldn't ask. In which case you may try using triggers, see this post for an example. Triggers are bad for performance, mind you.
Those who do not define foreign keys tend to work out all DELETE
s in application code.
A database is a place to store data. An application is where that data is manipulated.
MySQL cannot "send email" or otherwise reach outside of itself.
So... I would have a daily 'cron' job in the OS open the "events" table, read all the rows, compute who needs a reminder, send out the emails, and remove any expired rows from the table.
If you have only thousands of entries in the table, this is quite manageable; if you have millions, then there needs to be some way for the SELECT
to filter out most of the table, thereby lightening the load on the app.
To accommodate February, you might want to say 'last' instead of '30th'. That can be computed as "go forward 1 month, then back up 1 day". Or, in MySQL, date + INTERVAL 1 MONTH - INTERVAL 1 DAY
.
Your definition of Event Reminders table
is confusing -- is it a list of future reminders to issue? Or a list of past reminders sent out. Pick one. You seem to need to remember that you have already sent out a reminder; so I prefer that. Pre-computing the 'future' is not worth the effort (as I already pointed out).
Best Answer
Something like this:
But first, run a select to see if it will delete the correct rows: