存储过程作为后端

好的，不是存储过程，因为PostgreSQL拥有函数，但是尽管如此，我们还是摆脱了Django REST Framework，只在数据库中编写了整个逻辑。我立刻觉得自己年轻了15岁（我认为那是当这个概念宣布死亡并过世的时候）

到目前为止，已经迁移了3个项目：1.外汇CRM 2.学校的医疗平台3.酒店雇用的HR系统

概念：1.数据库中的整个业务逻辑（PostgreSQL）2.使用PostgREST的REST接口3.前端：Vue或Angular / ionic 4.看起来不错，没有后端！至少不是传统意义上的。取而代之的是，一些小型的“一劳永逸”（Go，Python）微型应用程序在世界各地的NOTIFY频道上进行监听。其中一个发送电子邮件，另一个是PDF转换器，另一个发送SMS

我不会概述这种方法的好处。太多了-从每个用户的出色权限（行，列）到性能提高以及介于两者之间的所有内容。

“数据库应该存储数据而不是逻辑！” —好吧，不。这称为数据库，而不是数据袋。数据库是处理数据的专用引擎。而且他们在这方面非常高效。更不用说-大多数工作后端都在处理数据。这对于原型制作很有用。不幸的是，原型经常以更新的连接字符串和debug = False登陆生产。

“代码是无法维持的烂摊子” —没有关于什么代码属于哪里的规则并不是技术问题。出现编码原理是有原因的-我们在Java中遵循它们，在SQL中应该遵循它们。我的理解是：没有明确的建议如何编写，存储和维护SQL代码。我了解没有任何准则。但是，这又不是技术问题。仍然是人的问题。

“让人们直接连接到数据库是一种疯狂” –是的。 PostgREST与连接数据库无关。

令人着迷的可移植性…便携式应用程序仍连接到“不可移植”的数据库，因此您可以看到移植的方向。

“这比ORM更好吗？”。快速浏览一下由ORM生成的代码就足够了。 Honoris causa进入实体框架。

“在大容量应用程序上，我会避免这种情况，因为通常水平扩展Web服务器要比sql服务器容易。”-这些Web服务器正在使用什么来存储数据？同样，典型的数据库将96％的时间用于日志记录，锁定等，而4％的时间用于实际数据操作，是的，这就是效率。在现实生活中，根本不可能通过单个网络端口的多个连接杀死数据库。您将长期耗尽可用端口。当然，这严格取决于SP代码的质量。性能提示：使用游标的开发人员应先切断手。这应该可以解决问题。

“疯！没人这样做！人们做到＆lt; the_week_of_the_week＆gt;而不是looooool” — —yyyyyyyyhhhhhhh…..

“无代码版本控制”：让我仅使用项目的一小部分，以说明我们如何解决此问题。文件夹中有数百个文件。重建数据库就像执行一行bash循环一样简单（我每隔几分钟执行一次）：

对于我在`ls [0-8] * / *。sql`中；做psql -U＆lt; user＆gt; -h本地主机-d＆lt; dbname＆gt; -f $ i;完成

它具有所需的全部内容：（1）表，然后是（2）联结/查找表，然后是（3）视图，过程，触发器和插入（用于重建数据库）

它需要遵循流程，但是至少在Django中，您需要使用ORM模型执行相同的操作。 您不能只在同一项目中的应用程序之间随机导入模型。 第2节“连接”等效于ManyToMany，让我们避免ALTER TABLE插入对在重建期间尚未创建的表的引用。