所以说这可能是主观的。我希望不会 - 我似乎无法理解这在实践中是如何运作的，而且它似乎是一个特定的技术问题，我希望得到明确的答案。
上下文： LAPP堆栈。
我已经读过，使用单个数据库用户作为数据库所有连接的登录，并从那里自己处理安全性，这是一个坏主意。数据库有足够的安全模型，使用它们是有意义的。
数据库句柄有一些与之相关的资源成本，因此存在Apache :: DBI，DBIx :: Connector和DBI :: connect_cached（），以重用最近的数据库连接。利用它们可以避免连接数据库的成本，从而加快Web应用程序的运行。
这些似乎是相互排斥的最佳实践的原因在于，根据我的理解，＃1意味着任何数据库连接都将使用单独的每用户凭据进行，这意味着（如Apache::DBI documents）使用此类连接可能会很快导致数据库后端耗尽连接。
PostgreSQL的默认最大连接数为100。
对于运行prefork MPM的Apache 2，服务器的默认数量和乘以子进程的数量远远超过了这个数量，所以看起来Apache :: DBI的文档是正确的。
因此问题：人们在实践中做了什么？
这是否意味着使用LAPP堆栈的人通常使用单个数据库用户连接，并实现他们自己的安全/权限模型？或者这是否意味着他们没有联系？或者，如果他们使用LAPP堆栈，他们会根据速度与安全需求在这两种策略之间做出选择，如果他们需要两者，请使用桌面应用程序或其他连接模型吗？
或者，如果这些事实上不是相互排斥的策略，我在这里的理解中缺少什么？
答案 0 :(得分：3)
我已经读过，使用单个数据库用户作为数据库所有连接的登录，并从那里自己处理安全性，这是一个坏主意。数据库具有足够的安全模型，使用它们是有意义的。
你可能误读了这个，或者在一个偏颇的位置阅读它。更加平衡的观点（希望如此）：
在数据库中管理perms（ACL或RBAC或其他）是一个血腥的混乱，很难做对。如果做得不正确，它也会削弱性能（想想：“选择*来自表连接perms，其中convoluted_permission_scenario”。）根据你的要求，你会获得或多或少的极端观点，例如：这是（非常有争议的）Zed Shaw：http://vimeo.com/2723800。
在数据库级别管理权限同样是一个血腥的混乱。并非所有引擎都实现行级权限，即使这样，偶尔也会出现泄漏。例如，如果调用raise，调用where子句中的函数可以（可以？）在Postgres中泄漏行（直到最近的版本？）。坦率地说，如果你经历了对正在发生的事情的肤浅分析，它基本上等于前者 - 只是标准化和（通常）在C中。
在没有数据库的情况下管理应用级的权限也一团糟。除非您处理大量数据，否则无论您何时需要在SQL之外加入，它都会削弱性能。如果你尝试一下，你会做得很好......直到你的数据库变得太大而基本上没有。
因此，简而言之：无论你在哪里管理，它都是一团糟。因为权限是一团糟。除了休闲和理想主义的“Joe需要对这组节点进行写入访问”之外，您还需要应对更多的实际场景，例如“约翰正在度假去圣诞节并需要暂时委托他的写入权限这套节点给他的助手Jane“。此外，无论您选择哪种方案，您都需要来管理读取访问权限（通常是最常用的），以便快速扩展以便进行扩展。没有银弹。
此外，即使在上述第一个和最后一个场景中，最好有三个DB用户。一个用于读取，一个用于读取/写入，一个用于架构更改。大多数应用程序没有，因为这是另一个血腥的混乱，以这种方式配置您的ORM，因此每个应用程序典型的一个数据库用户。
无论如何，回到你的问题：人们在实践中做的是一个或两个数据库用户（读取与读取/写入/修改），在数据库本身内实现RBAC或ACL，并避免访问限制逻辑，如瘟疫出于性能原因，面向公众的页面。