Postgres已经拥有功能齐全的用户管理系统。为什么我要复制这个功能并在其上再使用另一个？而且我认为这是管理用户和管理用户的合适场所。组，因为它允许细粒度控制。我错了吗？是否有一些php库已经完成了呢？ 我应该补充说，有问题的应用程序不是公共网站，而是在私有网络中工作的企业应用程序。
答案 0 :(得分：5)
我强烈建议应用程序设计人员使用PostgreSQL的用户和角色系统......但出于多种原因，将应用程序用户与数据库用户进行1：1映射通常并不实用。
PostgreSQL角色在所有数据库之间共享（尽管他们不必被授予除一个以外的任何权利）
您不能将普通应用程序表中的外键引用引用到PostgreSQL用户表
没有功能或其他界面来通过密码验证用户。您必须建立新的连接以通过密码进行身份验证。这打破了连接池。
相反，我建议您在数据库中使用几个角色：
数据库所有者角色。此用户/角色拥有数据库及其中的表。用于更改数据库结构的脚本（＆＃34;迁移＆＃34;依此类推）以此用户身份运行。
一个webapp角色。这是应用程序在建立池化连接时所连接的角色。这只是GRANT仅限日常运行时应用所需的访问权限。它无法更改表格结构，删除表格等。如果某个表格仅应附加，则您不会授予UPDATE此角色的权限。
（可能）脚本等的一些维护角色，这些角色只能访问他们的任务所需的内容。
使用普通表管理应用程序用户。
有时您还需要为特定类别的用户提供其他数据库角色。如果您正在处理具有不同权限级别，部门等的应用程序，这可能很方便.webapp可以SET ROLE切换角色，因此如果＆＃34; joe＆＃34;连接，你知道＆＃34;乔＆＃34;是在帐户中，你是＆＃34;设置角色帐户＆＃34;在为joe运行查询之前。这是更先进的，大多数人都不需要它。
我认为使用PostgreSQL用户管理的主要时间是有意义的，即应用程序具有相当复杂的访问要求，并且不需要大量不同的用户（数千，而不是数百万）。对于webapps，我会坚持使用普通的数据库表，只需从webapp连接池角色中分离出一个＆＃34; db admin＆＃34;角色。
答案 1 :(得分：1)
虽然可能，AFAIK尚未完成。
您的应用程序无法移植到其他数据库，而且mysql在Web应用程序中非常流行。
相反，您通常根据自己的需要设计用户表，自己编写组和访问管理，或者使用众多库中的一个。
（注意PG角色系统的投票）
答案 2 :(得分：0)
您不在应用程序中使用操作系统的用户管理，因为每个层都使用用户授予其管理的对象的权限。操作系统允许用户授予进程，文件等权限.RDBMS允许用户授予对表，模式，序列等的权限。
这些用户可能不会在您的应用程序层中使用，因为面向业务的对象因此权限是不同的。