Linking foreign keys across multiple databases: direct, or using an intermediary table?
This is bordering on an opinion-based question, because of course anyone can have their own justification for either choice.
I would not choose to add the intermediary table, for a few reasons.
One is that as you know, the intermediary table cannot have a foreign key reference to a table on another MySQL instance. Foreign keys can span schemas, but not instances.
If you need to run special scripts to clean up the intermediary table anyway, that special script should be able to encode clean up tasks for all the blog tables. I assume at least the number of blog tables remains relatively stable. You aren't going to be adding so many blog tables in custom ways that this becomes a burden to maintain the cleanup script.
The intermediary table therefore seems like an extra step that just complicates things, and takes extra storage.
I've worked at several companies that eschewed the use of foreign key constraints in any case, because they make some operation tasks harder, for example schema changes. Also because they incur locking behavior that you probably don't expect. In the absence of the constraints, you can't get the ON DELETE CASCADE feature.
Like I said above, this is subject to opinion. You could easily ask, &quot;but what if the priorities are a bit different...?&quot; Of course, you must make this decision based on your requirements and priorities.