存储过程作为后端

2020-12-04 20:59:30

好的,不是存储过程,因为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代码的质量。性能提示:使用游标的开发人员应先切断手。这应该可以解决问题。

“疯!没人这样做!人们做到< the_week_of_the_week>而不是looooool” — —yyyyyyyyhhhhhhh…..

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

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

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

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