I'm trying to bounce this off of other DBAs out there to see what your experience has been around this subject.

It's simple. We have a project to deploy a new COTS application. The vendor provides a set of scripts that need to be ran against the database to "install" the application schema. These scripts include being ran by someone with DBA access (me).

Of course I review the script. I come to find that the first script I ran creates the schema owner and grants the schema a lot of privileges. Among those are:

ALTER DATABASE
ALTER SYSTEM
ALTER TABLESPACE
ALTER USER
BECOME USER
GRANT ANY PRIVILEGE
... and so on (these are just the high level ones).

They are just shy of granting DBA role.

After the review I questioned the vendor reps and asked are these privileges necessary. They said yes. They said the app was designed so that it can create additional tablespaces/schema. The application manages certain kinds of "projects" and supposedly when end-users create new projects, the application will create new schema and tablespaces. And apparently, there are various other "functions" within the application that require things like ALTER DATABASE and ALTER SYSTEM.

It just blows my mind how a software development team would have approach their design in this fashion. For instance, instead of creating whole new schema for every "project" in the app, why not just create a new set of tables/objects within the existing schema??

In my modest experience as a DBA, this is the first time I've seen an application behave in such a way.

At the same, the vendor has submitted that most of their clients do not have a formal IT group to support back-end systems, so they've provisioned these functions within the application to allow end-users to do "database administration work" without needed to hire administrators.

Just like in other posts I've seen, the concern is around who is then responsible for a database where administrative access is allowed outside the primary DBA group?

Where you guys can help me is provided any whitepaper out there that goes against the way this application has been designed. The vendor reps admits their approach is outside the norm, but tries to sell it as a "paradigm shift" in application development, which I think is a bunch of bull.

Any feedback would be greatly appreciated. Thanks.