【发布时间】：2015-10-28 00:38:10
【问题描述】：
Postgres 已经拥有功能齐全的用户管理系统。为什么我要复制此功能并在此基础上使用另一个功能？而且我认为这是管理用户和组的正确位置，因为它允许细粒度控制。我错了吗？是否有一些 php 库已经这样做了？
我应该补充一点，有问题的应用程序不是公共网站，而是在专用网络中运行的公司应用程序。
【问题讨论】：
标签： php postgresql web-applications
【发布时间】：2015-10-28 00:38:10
【问题描述】：
我强烈建议应用程序设计人员使用 PostgreSQL 的用户和角色系统……但出于多种原因，将应用程序用户与数据库用户进行 1:1 映射通常不切实际。
PostgreSQL 角色在所有数据库之间共享（尽管他们不必被授予任何权限，除了一个）
您不能有从普通应用程序表到 PostgreSQL 用户表的外键引用
没有通过密码验证用户的功能或其他接口。您必须建立新连接才能通过密码进行身份验证。这会破坏连接池。
相反，我建议您在数据库中使用几个角色：
数据库所有者角色。此用户/角色拥有数据库和其中的表。更改数据库结构（“迁移”等）的脚本以该用户身份运行。
一个网络应用角色。这是应用程序在建立池连接时连接的角色。这是
GRANTed，只是应用程序在日常运行时需要的访问权限。它不能更改表结构、删除表等。如果一个表应该是仅追加的，则您不授予该角色UPDATE权限。（可能）脚本等的一些维护角色，这些角色只能有限地访问他们完成任务所需的内容。
您使用普通表管理您的应用程序用户。
有时您还希望为特定类别的用户提供额外的数据库角色。如果您正在处理具有不同权限级别、部门等的应用程序，这会很方便。网络应用程序可以SET ROLE 切换角色，因此如果“joe”连接并且您知道“joe”在帐户中，您可以“设置角色”在对 joe 运行查询之前。这个比较高级，大部分人都不需要。
我认为直接使用 PostgreSQL 用户管理的主要时间是当应用程序具有相当复杂的访问要求并且不需要大量不同的用户（数千，而不是数百万）时。对于 webapps，我会坚持使用普通的数据库表，只需将“db admin”角色与 webapp 连接池角色分开。
【讨论】：
-
鉴于该应用程序使用 PHP（没有连接池问题）并将用于公司网络（一次最多有数百名用户），并且确实需要高级访问管理（我在等待对于 9.5 中的 RLS）您仍然不建议使用它吗？
-
@nii 说 PHP 意味着没有连接池问题是没有意义的。您可以使用 PHP 中的池，或者像 PgBouncer 这样的代理池，这样做很常见。但是，对于数百个并发用户，您可能不需要这样做。如果您正在考虑使用 RLS 等，那么这可能是值得的。拥有数据库内用户的好处是您可以
GRANT每个用户获得他们需要的特定角色，而GRANT这些角色只有他们需要的特定权限。 -
你对连接池的看法是对的，我第一次没有读到它，将来可能有必要。而现在我认为我只是可以为不同部门使用具有不同RLS访问权限的几个角色，并坚持应用级别的用户管理系统。
-
补充您的答案，还有另一种情况，当 db 级用户管理是正确的选择：当一个数据库被多个应用程序使用时
AFAIK 尽管有可能，但这并没有完成。
您的应用程序无法移植到其他数据库，而 mysql 在 Web 应用程序中非常流行。
相反，您通常会根据自己的需要设计用户表，并自己编写组和访问管理，或者使用众多库之一。
（对注意到 PG 角色系统的赞成票）
【讨论】：
-
考虑移植到其他数据库与移植到其他语言是一样的。这意味着使用所有 rdbms（例如 mysql）中最不常见的功能。如果您的开发是一个普通的论坛软件，这很有用，如果您的开发是一个专门的面向业务的应用程序，则会适得其反。
-
我认为不需要将我的应用程序移植到另一个 DBMS。因此，将其与 Postgres（最好的开源 DBMS）联系起来并不是一件坏事。
-
@greg 我已经在 pltcl（使用位字符串）中编写了我的用户和组管理，以便在没有 PHP 的情况下移植到其他语言/批量访问。
您不要在应用程序中使用操作系统的用户管理，因为每一层都使用用户来授予对其管理的对象的权限。操作系统让用户授予对进程、文件等的权限。RDBMS 让用户授予对表、模式、序列等的权限。
这些用户可能不会在您的应用程序层中使用，因为面向业务的对象因此权限不同。
【讨论】：
-
很高兴听到您的意见。谢谢你的 Pomm BTW，我在这个应用程序中大量使用它。