Nice to hear from you.
Maybe others with more experience than I can answer this better – but I think that self registration is most useful for an installation where all the data is available to the public. Users can self-register at the root organization and then have access to all the data. Typically the self-registered users can see all the data in the system but not change it. I agree with you that self-registration is not very good if the user will be restricted to an organisation unit, because the user cannot select which organisation unit.
For a country with many users and many organisation units, I think the most common way is to create an organisation unit hierarchy that follows an administrative hierarchy. Hospitals are grouped by the lowest level of administrative group. The lowest level groups are grouped into administrative groups at the next higher level. And so on. If there are multiple users within a hospital, you can create one or more user administrators for that hospital who are responsible for the users in that hospital. Then you create one or more users at the lowest administrative group who are responsible for creating the user administrators in each hospital. Then at the next higher administrative group, you create users who can create the users in the lowest administrative group. And so on. So the user administration is distributed according to an administrative hierarchy, which the organisation unit hierarchy is designed to follow. This may be the easiest way to manage a very large number of DHIS2 users.
In the PEPFAR instance, there are over 110,000 organisation units, and this works fine in DHIS2. There are about 23,000 users. I don’t see any reason why DHIS2 should not support 100,000 users, though I don’t know if we have any current instances with that many. Maybe someone else knows.
I think the best design for DHIS2 is where each organisation unit has a limited number of direct children. For example, in the PEPFAR instance, we had the global level as the root, and countries as the next level down. The system worked better when we introduced an organisation unit level “continent” between global and country, so each continent has a limited number of children countries, instead of all the countries being under the single global organisation unit. This means when a part of the organisation unit hierarchy is loading, there are fewer organisation units to load at each level, so it performs better.
Likewise, the best design is where each user is assigned to as few organisation units as possible. Ideally each user would be assigned to only one organisation unit, which includes the part of the subtree where the user is authorized to work. But a user can be assigned to a small number of organisation units as well. If this number gets too large it can be a performance problem, as @jaime.bosque says.
If you have a user that is assigned to an organisation unit with many sub-orgs, the user does not have to be assigned to all the sub-orgs also, only to the parent organisation unit.
I hope this helps. Let us know if you have other questions, or maybe we didn’t understand well the questions that you had.