使用 Postgresql 作为中间层。需要意见答案

【问题标题】：Using Postgresql as middle layer. Need opinion使用 Postgresql 作为中间层。需要意见
【发布时间】：2009-12-13 01:05:59
【问题描述】：

我需要一些意见。

我要为朋友开发一个 POS 和库存软件。这是一个单人小规模项目，所以我想让架构尽可能简单。

我正在使用 Winform 开发 GUI（Web 界面对 POS 软件没有意义）。对于数据库，我使用的是 Postgresql。

该程序将根据用户角色控制访问，因此我必须使用 Web 服务器开发一个中间层来控制用户访问，或者我可以直接在 Postgresql 中设置用户权限。

开发中间层会很耗时，维护也会更复杂。所以我更喜欢直接在数据库中设置访问控制。

现在看来，使用数据库来控制用户访问很麻烦。我必须为每个角色设置权限。更不用说对于某些表，权限是列级别的。这使得关于安全性的推理变得非常困难。

所以我现在要做的是将所有表设置为不可访问，除非超级用户。该程序将使用公共角色连接到数据库。由于公共无法访问这些表，因此我将使用 SECURITY DEFINER（具有超级用户角色）创建可公开访问的存储函数。访问表的唯一方法是使用这些函数。

我会将用户角色和密码放在一个表格中。因为非超级用户无法访问用户表本身，所以我将创建一个登录功能，我们称之为fn_login(username, password)。如果登录成功，fn_login 将返回一个会话密钥。

要调用其他函数，我们需要为用户提供会话密钥，例如：fn_purchase_list(session_key)、fn_purchase_new(session_key, purchase_id, ...)。

这样，我将存储的函数视为 API。添加新用户会更容易，因为我只需要在用户表中添加新行而不是添加新的 Postgresql 角色。我不需要在列级别设置权限。所有控件都将以编程方式完成。

那你怎么看？这种方法是否可行且可扩展？有没有更好的方法？

谢谢！

【问题讨论】：

【解决方案1】：

我相信有更好的方法来做到这一点。但由于您尚未讨论您需要哪种类型的安全性，我无法详细说明。

由于您是在 .NET 中开发应用程序代码，因此需要信任该代码（与 Web 应用程序不同）。因此，您为什么不简单地在应用程序代码中而不是在数据库中实现您的角色和权限？

我对您所述方法的担忧是存储过程的人力开销。宁愿看到你在 C# 中编写声明的函数，而不是在 PostgreSQL 中。然后，可以应用标准版本控制和软件开发技术。

【讨论】：

【解决方案2】：

如果您等到有人在您的数据库中检查安全性，我认为您为时已晚。这是 90 年代末出现的客户端/服务器心态。这是 n 层架构流行的部分原因。客户端/服务器无法像 n 层解决方案那样水平扩展。

我建议您更好地利用中间层。安全性应该是一个跨领域的问题，它比你的持久层更进一步。

【讨论】：

并非每个应用程序都需要扩展。 90 年代的客户端/服务器技术对许多组织来说都是可行的。由于大型组织实际上设法通过使用该技术来获得这一简单事实表明它是有效的。也许不是最佳的，但至少是可行的。很可能，此应用程序不会出现这些问题。当然有限制，这是一个设计考虑因素。
但是提问者特别问“这种方法是否可行且可扩展？”可行的？当然。可扩展？这取决于一个人需要走多远，并且没有任何提示。
好吧，我读到“一个人的小型项目，所以我想让架构尽可能简单”，并认为这个问题已经得到解答。

【解决方案3】：

如果数据库安全的管理是问题，那么您应该添加自动化管理的任务。这意味着您可以使用数据库表存储更高级别的数据，然后您的应用程序可以将该数据转换为数据库所需的适当细节和工件。

听起来数据库包含您需要的详细信息，您只需要促进该详细信息的管理，并将其滚入您的应用程序。

【讨论】：

【解决方案4】：

我的诚实建议：不要发明 POS 和库存软件。选择existing projects 之一，让它变得更好。

【讨论】：