数据库中应该有多少业务逻辑？

我正在开发一个多用户应用程序,它使用(postgresql-)数据库来存储其数据.我想知道我应该将多少逻辑转移到数据库中？

例如,当用户要保存他刚刚输入的一些数据时.应用程序是否应该将数据发送到数据库,数据库是否确定数据是否有效？或者应用程序应该是行中的智能部分并检查数据是否正常？

在我工作的最后一个(商业)项目中,数据库非常倾倒.没有约束,没有视图等,一切都由应用程序统治.我认为这非常糟糕,因为每次在代码中加入某个表时,都会有相同的代码来检查访问是否有效一遍又一遍地重复.

通过将逻辑转移到数据库(带有函数,triger和约束),我认为我们可以在应用程序中保存大量代码(以及许多潜在的错误).但我害怕将大部分业务逻辑放入数据库中将是一个回旋镖,有一天它将无法维护.

是否有一些现实生活中批准的指导方针？

如果您不需要大量的分布式可扩展性(想想拥有亚马逊或Facebook等流量的公司)那么关系数据库模型可能足以满足您的性能需求.在这种情况下,使用具有主键,外键,约束和事务的关系模型可以更容易地维护数据完整性,并减少需要完成的协调量(并且一旦您停止使用任何协调,请相信我)在这些事情上,你需要和解 - 即使你和他们你也可能会因为错误而被解决.

但是,大多数验证代码比C#,Java,Python等语言更容易编写,而不是像SQL这样的语言,因为这是他们设计的类型.这包括验证字符串格式,字段之间的依赖关系等等.所以我倾向于在"普通"代码而不是数据库中执行此操作.

这意味着实用的解决方案(当然也就是我们使用的解决方案)是在有意义的地方编写代码.让数据库处理数据完整性,因为它是擅长的,并让"正常"代码处理数据有效性,因为这是它擅长的.你会发现一大堆不合适的情况,以及在不同的地方做事情的意义,所以要务实,并根据具体情况进行权衡.