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

我需要一些意见

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

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

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

开发中间层将非常耗时，而且维护将更加复杂。所以我更喜欢直接在数据库中设置访问控制

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

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

我将把用户角色和密码放在一个表中。由于非超级用户无法访问用户表本身，因此我将创建一个登录函数，我们称之为

fn\u login（用户名、密码）

。如果登录成功，fn_登录将返回会话密钥

要调用其他功能，我们需要为用户提供会话密钥，例如：

fn\u purchase\u list（会话密钥）

，

fn\u purchase\u new（会话密钥，购买id…）

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

那你觉得呢？这种方法可行且可扩展吗？有更好的方法吗

---

谢谢

我相信有更好的方法。但是，由于您还没有讨论您需要什么类型的安全性，我无法详细说明细节

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

---

我关心的是存储过程的人为开销。我更希望看到您用C#而不是PostgreSQL编写所述函数。然后，可以应用标准版本控制和软件开发技术。

我相信有更好的方法。但是，由于您还没有讨论您需要什么类型的安全性，我无法详细说明细节

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

---

我关心的是存储过程的人为开销。我更希望看到您用C#而不是PostgreSQL编写所述函数。然后，标准的版本控制和软件开发技术就可以应用了。

如果你等到有人在你的数据库检查安全性，我想你就太晚了。这种客户机/服务器思维在90年代末就已经过时了。这也是n层体系结构流行的部分原因。客户端/服务器无法像n层解决方案那样水平扩展

---

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

如果你等到有人在你的数据库检查安全性，我想你就太晚了。这种客户机/服务器思维在90年代末就已经过时了。这也是n层体系结构流行的部分原因。客户端/服务器无法像n层解决方案那样水平扩展

---

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

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

---

听起来数据库有您需要的详细信息，您只需要方便管理该详细信息，并将其应用到您的应用程序中。

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

---

听起来数据库中有你需要的详细信息，你只需要方便地管理这些详细信息，并将其应用到你的应用程序中。

我真诚的建议：不要发明POS和库存软件。拿一个，让它变得更好。

我真诚的建议：不要发明POS和库存软件。选择其中一个并使其更好。

并非每个应用程序都需要扩展。90年代的客户机/服务器技术对于许多组织来说都是可行的。因为一个简单的事实是，大型组织实际上通过使用该技术获得了收益，这表明它是有效的。也许不是最优的，但至少是可行的。而且，这个应用程序很可能不会出现这些问题。当然也有局限性，这是一个设计上的考虑因素