postgresql - "best practices"关于连接句柄重用和数据库用户设计是否相互排斥？

Question

SO 表示这可能是主观的。我希望不是——我只是似乎无法理解这在实践中是如何工作的，这似乎是一个足够具体的技术问题，我希望有一个明确的答案。

上下文:LAPP 堆栈。

1. 我读到，使用单个数据库用户作为所有数据库连接的登录名，并从那里自己处理安全性，是一个坏主意。数据库有足够的安全模型，使用它们是有意义的。

2. 数据库句柄具有一些与之相关的资源成本，因此存在 Apache::DBI、DBIx::Connector 和 DBI::connect_cached()，以重新使用最近的数据库连接。利用它们应该可以避免连接数据库的成本，从而使网络应用程序更快。

这些似乎是相互排斥的最佳实践的原因是，根据我的理解，#1 意味着任何数据库连接都将使用单独的每个用户凭据进行，这意味着(如 Apache::DBI documents )重新使用此类连接可能会很快导致您的数据库后端耗尽连接。

PostgreSQL 默认最大连接数为 100。

对于使用 prefork MPM 运行的 Apache 2，默认的服务器数量乘以每个服务器允许的子进程数量远远超过了该数量，因此 Apache::DBI 的文档似乎是正确的。

因此问题:人们在实践中会做什么？

这是否意味着使用 LAPP 堆栈的人们通常使用单个数据库用户进行连接，并实现自己的安全/权限模型？或者这是否意味着他们不汇集连接？或者，如果他们使用 LAPP 堆栈，他们会根据速度与安全需求在这两种策略之间进行选择，如果他们需要两者，则选择桌面应用程序或其他连接模型？

或者，如果这些实际上不是相互排斥的策略，那么我在这里的理解中缺少什么？

Answer 1

I've read that using a single database user as the login for all connections to the database, and handling security yourself from there, is a bad idea. Databases have sufficient security models and it makes sense to use them.

您可能误读了本文，或者在一个高度偏见的位置阅读了它。更平衡的观点(希望)是这样的:

• 在数据库中管理权限(ACL 或 RBAC 或其他)是一团糟，而且很难正确处理。如果做得不当，它也会削弱性能(想想:“select * from table join perms where convolulated_permission_scenario”。)根据你问的是谁，你会得到或多或少的极端观点，例如:这是(非常有争议的)Zed Shaw:http://vimeo.com/2723800 .

• 在数据库级别管理权限同样是一团糟。并非所有引擎都实现行级权限，即使如此，偶尔也会出现泄漏。例如，如果 raise 被调用，在 where 子句中调用函数可能(可以？)泄漏 Postgres 中的行(直到最新版本？)。坦率地说，如果你对正在发生的事情进行肤浅的分析，它基本上相当于前者——只是标准化并且(通常)用 C 编写。

• 在没有数据库的情况下在应用级别管理权限也是一团糟。从需要加入 SQL 之外的那一刻起，无论您做什么，都会降低性能，除非您处理的数据量很小。如果你尝试一下，你会做得很好......直到你的数据库变得太大而你基本上不会。

所以，简而言之:无论你在哪里管理，这都是一团糟。因为权限是一团糟。除了随意和理想化的“Joe 需要对这组节点的写权限”之外，您还需要应对更实际的场景，例如“John 要去度假过圣诞节，需要暂时将他的写权限委托(delegate)给这组节点交给了他的“助理简”。此外，无论您选择哪种方案，您都需要以快速的方式管理读取访问(通常是最频繁的)，以便可以扩展。没有 Elixir 。

此外，即使在上述第一个和最后一个场景中，拥有三个数据库用户也是理想的选择。一种用于读取，一种用于读/写，一种用于架构更改。大多数应用程序不这样做，因为以这种方式配置 ORM 又是另一场血腥困惑，因此通常每个应用程序只有一个数据库用户。

无论如何，回到你的问题:人们在实践中所做的是一两个数据库用户(读与读/写/修改)，在数据库本身中实现 ​​RBAC 或 ACL，并避免像瘟疫一样的访问限制逻辑出于性能原因面向公众的页面。