How to logically collect logic from 3 queries in Mysql?

Question

MySQL

Hello! Moderators, please do not correct the tags, because the question applies equally to all three.
Could you tell me how to build the logic in this case?
I have such a problem: before sending a push notification to the user, I need to make 3 queries to the database. Action: "a post is added to the site" (conditionally, to simplify the explanation).
1. From the AddPostPushCreator model, we request IDs of users whose settings indicate that they want to receive notifications from the "Business" category.
2. Request "Check whether each of these users is configured to receive push notifications on this topic" (i.e. the user could enable notifications in the application, but disable push for this type of notifications).
3. Request to receive the key of the device to which you want to send a push notification.

The problem is this:
Requests 2 and 3 are essentially the same for any type of push notification, be it "someone wrote a private message", "someone subscribed", "someone liked", etc. So I ruled out the option of combining them with the first query. Because it would be necessary to prescribe the same lokiu for each type of notification. Therefore, I have to get the ID with the first request, but let's assume there are tens of thousands of them, which means I cannot insert them into the 2nd and 3rd queries using WHERE IN () because there is a limit.

I ask for advice, just at least in words, how such a situation can be beaten

Answer 1

you can get a list of all who should receive a notification with one request. immediately with the device key. and form a queue at the moment the event occurs. and no need to complicate

Answer 2

I didn’t quite understand the problems, and why it’s impossible to write a view for each type of notification.
But as a variant with perversions: The second and third request should be washed down in the view.
Be clear about how many fields you need for all 20 notifications.
Create a procedure in which the input is the category, notification type.
Inside, write branching logic for different notifications, but always make queries that return the same number of columns. Here you use one view, which does not need to be duplicated 100500 times in requests.