所以我最近才开始做类似于成熟的 Oracle DBA 工作的东西，所以我仍在学习我工作中管理部分的许多基础知识。我的任务是使多个应用程序数据库达到一定的专业标准（我故意含糊其辞）。这些标准之一是支持应用程序的对象的所有者通常也不应该经常使用它们。主要的例外是 DBA，但仅适用于我们定期维护的某些类对象，例如索引。除了执行安装和维护任务时，应禁用应用程序对象所有者。
这最终让我想到了我的问题：谁应该拥有这些应用程序对象。我们是否应该让一个创建对象的用户在其余下的生命周期中基本上被禁用，并为这个或那个角色提供必要的使用权限？DBA 是否可以拥有所有应用程序对象，或者他们应该只拥有每天/每周维护的那些对象？显然，确切的答案将取决于组织的需求和该标准具体要求的内容，但是这里应用程序对象所有权的最佳实践是什么？
这个问题可能太宽泛了，所以如果我需要编辑它以使其更具体，请告诉我。我真的不知道从哪里开始，甚至不知道该问什么问题。感谢您的任何帮助，您可以提供。
最小权限原则要求两件事：运行时用户（或人类用户登录）不应拥有对象，因为您无法阻止他们修改或删除它们（在 Oracle 上）。
同样的原则还建议您不需要为想要更新应用程序对象的用户提供广泛的权限。
两者结合起来建议：让一个系统用户拥有应用程序对象，另一个系统用户可以访问这些对象以进行运行时登录。仅使用 DBA 来设置这些用户。
它在 MSSQL 上有点不同，但基本上您希望避免让运行时用户具有 dbo 角色。
一般来说，拥有一个由用户帐户拥有的通用数据库对象是个坏主意。如果用户的帐户被禁用或消失，就会出现问题。
我是 SQL Server 专家，所以情况有点不同，但我喜欢拥有一个服务帐户作为数据库所有者，因此我们知道该帐户不会在员工离职时消失。
在 Oracle 中，通常设置拥有表和存储代码（包、函数等）的所有者用户。这是为此目的的专用用户。
在支持多个应用程序的较大数据库上，可能有多个这样的所有者。他们可以根据需要被授予访问其他用户拥有的表的权限。
应用程序和用户将拥有自己的用户标识。这些通常没有创建数据库对象的能力。他们被允许访问他们需要的代码，以及执行他们的目的所需的任何表。
正如其他人指出的那样，应该应用最小特权原则。可能仅允许用户对某些表进行选择（读取）访问。在某些情况下，他们可能可以访问列的子集（通过视图或其他机制）。
通常创建由 DBA 用户标识拥有的对象是不常见的。DBA 用户应该用来管理数据库。他们可以创建其他用户拥有的对象。如果所有者用户标识未被授予登录权限，则这是必需的。