Note that Q67 tries to make similarities between LAMP apps like nextCloud and Phorge, but nextCloud has not 400+ database tables. This is just a minimal indication of the complexity, that may indicate that this design principle may be not totally suitable for this.

This is not to indicate that it's impossible to do, it's just to indicate that your direction is not so obvious. But, anybody is encouraged to fork and work on this. Forking is good in Phorge.

Your objection concerning the reference to Nextcloud is based on quote mining. It is neither germane nor accurate.

The documentation gives no indication that 400 tables in a single database is inherently problematic.

I also doubt the underlying storage of tables in a cluster, or operation for query processing, is particularly different based on whether the tables are spread in many databases within the cluster versus consolidated within one.

I have given technical arguments that I consider sound. It is entirely your choice whether to engage them, but I feel it is unhelpful to circumvent them through constructing a straw man.

Database management systems are designed to scale. Phorge is not the first application to manage a database with scalability expectations, and circumvention of the design principles for the database system itself is not included within the accepted solutions for achieving a scalable database.

The current approach is in fact not only arduous and error-prone from an administrative standpoint, but also a source of operational fragility and an obstacle to data protection.

I understand your interest in this simplification. I think your opinion is helpful, useful, and I hope you will somehow solve your problem.

But, please also try to understand that you cannot just convince all Phorge system administrators that they are alien if they like to "just move" a single database to another host, instead of having to design table partitions, etc. :D

Therefore, this is not easy, and a compromise is necessary.

I am not intent on maintaining my own fork for private use, but the processing pathways for the segmented versus consolidated cases are only minimally different, and may easily be switched dynamically, within some hypothetical future version of the application, depending on the deployment.

If separate database connections are created and maintained, it is no matter if they happen to target the same database.

Again, you have not convinced me to work on that, for you, for free :)

If you or a friend of yours are able to have a fork that somehow does that (tomorrow, or in months or years), feel free to come back and propose a patch. We are here to review your code. The possibilities to have that merged are high, as long as the code is testable and it does not destroy other-people workflows.

If it is likely in principle that you would accept a patch, then it may be most sensible to leave the discussion open. Perhaps it would be found by someone wishing to contribute.

I also like to discuss. Please read this:

https://we.phorge.it/book/contrib/article/feature_requests/

In my opinion PROBABLY investing an unknown amount of hours in this will probably help you in simplifying the installation from Softauculus. Or, investing 10 minutes in contacting Softauculus to ask them "is it a problem if the app installs some phabricator_% databases?" would also contribute a lot in your goal.

I think you are misunderstanding the technical considerations.

The issue is not a flaw or limitation in Softaculous.

The issue is that administrators of database clusters create databases per request of application administrators, and grant the application administrators permissions to populate the databases assigned to them, but not to create new databases.

Database administrators are responsible for managing names of databases within each cluster, and for protecting each database from applications not assigned to it.

Such constraints were already explained in the original text.

Granting an application permissions to create (or to drop) arbitrary databases is not a responsible or agreeable policy for administrating a cluster, and placing constraints on a database name is not an agreeable design for an application.