我得到了一个“最佳实践”问题。我不是数据库管理员所以我对此没有很好的了解，但我们的管理员正在推动我们构建的每个应用程序都需要创建一个新的数据库用户（或者可能是每个用户的“ “应用程序”，以便他可以确定哪些用户可能正在占用资源。我理解这个决定背后的理论，但我想知道这是否是标准做法。在我看来，这将导致管理噩梦。例如，我们已经说过50多个内部运行的应用程序，所以如果每个应用程序都有不同的用户绑定，那么它不仅难以管理，而且我会看到很多这些应用程序具有重叠权限。如果要确定要使用哪个用户或者是否需要为每个新应用创建新用户，那将成为一件苦差事。
对此有何想法？
感谢。
答案 0 :(得分：4)
在某种程度上，它取决于“应用”的含义，因为这是一个非常有弹性的术语。这还取决于您是在谈论创建新用户，然后拥有特定应用程序的所有表，或者您是否正在讨论创建将用于登录数据库的新用户，但这些用户将可以访问存储在一组单独的（可能是更小的）用户模式中的对象。
如果50多个应用程序意味着您有50多个自包含的表集，这些表可以由50个独立的代码访问，那么为每个应用程序创建单独的用户和单独的模式是非常合理的。它可以更轻松地跟踪哪些应用程序使用最多的磁盘空间，哪些应用程序正在创建性能问题等。它还使得锁定每个帐户的权限变得相对容易，因为每个帐户只需要访问一个模式中的数据任何系统级权限授予都将特定于特定应用程序。
另一方面，如果你有50多个应用程序访问同一个数据库，那么这些应用程序可能更像是一个更大的应用程序的组件，最终需要共享对各种对象的访问权限。例如，如果您有一个应用程序让HR输入有关新员工，终止，辞职等的数据，另一个应用程序可让管理人员进入员工审核，第三个应用程序可让HR管理组织结构图，那么很可能所有这三个应用程序都需要访问相同的基本表集，可能只有少数例外。如果一个用户拥有员工表而另一个用户拥有存储组织层次结构的表并且第三个用户拥有存储员工评论的表，那将是非常烦人的。在技术上可以构建这种类型的系统，但是管理同义词，权限授予和构建过程可以非常快速地变得难以操作，此外当不同的应用程序在不同的应用程序中放置基本相同的数据时，更有可能引入数据完整性问题。表，因为他们不知道某些其他应用程序已经拥有该实体的表。
此外，您还必须考虑应用程序的部署方式。如果您有50个小型Java应用程序，比如连接到单个Oracle数据库的2个应用程序服务器，那么拥有50个独立的Oracle用户将使连接池面临挑战，至少可以说。即使每个连接池只有5个数据库连接，当您添加应用服务器或应用程序以及用户负载增加时，当应用服务器启动并创建更多连接时，您仍然在讨论50 * 5 * 2 = 500个数据库连接。虽然可以支持数百或数千个与数据库的连接，但这种方法也会产生各种管理难题。
根据管理员的具体目标，可能还有更好的方法（代替或单独的数据库帐户）。例如，Oracle提供了DBMS_APPLICATION_INFO包，应用程序可以轻松地使用它来添加检测以向DBA显示数据库会话当前正在执行的操作。这可以为DBA提供比仅具有单独的数据库帐户更细粒度的信息。例如，如果您有一个三层应用程序，当它从连接池中提取连接以传入实际用户的名称并SET_CLIENT_INFO来定义当前应用程序时，可以轻松调用SET_MODULE过程。甚至用户当前所处应用程序的哪个部分。然后将这些信息放在DBA已经查询的各种视图中，使DBA可以轻松地在消耗大量资源的会话上进行深入分析。看到人类用户是“JustinCave”，他目前处于“InventoryManagement”应用程序的“QuarterlyReporting”模块中，DBA可能从经验或上下文中了解该模块可能会发出长期运行但仍然很重要的查询。即使您有可以参考的应用程序日志来获取所有这些信息，使DBA可以直接使用它可以使故障排除更加高效，并有助于提高开发和支持组之间的通信效率。例如，DBA可以告诉应用程序开发人员，特定应用程序的特定模块似乎在创建性能问题，或者在月中询问为什么有人在QuarterlyReporting模块中而不是简单地说“InventoryManagement应用程序很慢“或要求其他人浏览应用程序日志，以弄清楚在特定时间点发生了什么。
答案 1 :(得分：1)
这是常见的做法，既可以是您的管理员引用的原因，也可以是您在应用程序中执行精确级别的读/写控制。通过为您的应用程序提供他们所需的权限，您可以限制潜在的安全违规行为。
@Rutt为每个applcation创建一个新用户。即使您的应用目前可能具有重叠权限，也无法保证应用的权限不会发生变化。您正在以一种不受其他应用程序新兴要求影响的方式对每组权限进行打沙。