Linking foreign keys across multiple databases: direct, or using an intermediary table?

I want to make a part of my application reusable, and that warrants moving the corresponding tables into a separate database. So for the sake of an example, please consider the two imaginary databases in the list that follows. (More databases sharing the same logic may be added as the project grows.) - users containing tables related to user sign ups, login and e-mail history, password reset tokens etc., as well as the accounts themselves; and - blogs having tables for posts, media files, comments, etc. Each table in the blogs database must obviously have an account_id column referring as a foreign key to users.accounts.id. (I do realise that to make it work both databases [must use InnoDB and reside on the same server](https://stackoverflow.com/questions/18274299/how-can-you-create-a-foreign-key-to-a-table-in-another-database-with-workbench).) My question is what would be a better practice: - direct reference to another database: - simply refer blogs.posts.account_id to users.accounts.id (repeat with all other blogs.* tables), - make each reference CASCADE ON DELETE; or - using an intermediary table: - create an intermediary table blogs.accounts having only one column called id; then - on one hand, refer every table inside the blogs database to that intermediary table (so blogs.posts.account_id to blogs.accounts.id, CASCADE ON DELETE); and - on the other hand, finish by referring this blogs.accounts.id to the 'upstream' users.accounts.id, make sure to CASCADE ON DELETE as well. The latter seems like an unnecessary complication. But the only advantage I can think of is this can make the setup future proof in case we end up having to still migrate one (or some) of the databases to another server: - If we link the tables directly, after the migration the blogs database will have lots of disparate account_id columns that won't CASCADE ON DELETE - But if these intermediary tables get disconnected from the upstream users.accounts.id, their neighbouring tables in each respective database are still linked to them. This way we can continue benefitting from at least somewhat integrity and CASCADEs. In other words, if a user gets deleted, all we have to do is have a script go through each of these *.accounts connector tables and delete the id counterpart once, and CASCADE will take care of the rest of the tables inside of that database automatically. Am I on the right track with this logic, or am I missing some other ways to handle this more effectively, and therefore reinventing the wheel?