我正在开发一个多用户应用程序，它使用 (postgresql-) 数据库来存储其数据。我想知道我应该将多少逻辑转移到数据库中？
例如当用户要保存他刚刚输入的一些数据时。应用程序是否应该只将数据发送到数据库并由数据库决定数据是否有效？或者应用程序应该是线路中的智能部分并检查数据是否正常？
在我从事的最后一个(商业)项目中，数据库非常垃圾。没有约束，没有观点等，一切都由应用程序决定。我认为这很糟糕，因为每次在代码中访问某个表时，都有相同的代码一遍又一遍地检查访问是否有效。
通过将逻辑转移到数据库中(使用函数、触发器和约束)，我认为我们可以在应用程序中节省大量代码(以及大量潜在错误)。但我担心将大部分业务逻辑放入数据库会是一个回旋镖，总有一天它将无法维护。
是否有一些现实生活中认可的准则可供遵循？
最佳答案
如果您不需要大规模的分布式可扩展性(想想像 Amazon 或 Facebook 等流量大的公司)，那么关系数据库模型可能足以满足您的性能需求。在这种情况下，使用具有主键、外键、约束和事务的关系模型可以更容易地维护数据完整性，并减少需要完成的协调量(相信我，一旦您停止使用任何这些事情中，您将需要协调——即使是由于错误，您也可能会这样做)。
但是，大多数验证代码用 C#、Java、Python 等语言编写比用 SQL 等语言编写要容易得多，因为这是它们的设计目标。这包括验证字符串格式、字段之间的依赖关系等。所以我倾向于在“普通”代码而不是数据库中执行此操作。
这意味着实用的解决方案(当然也是我们使用的解决方案)是在有意义的地方编写代码。让数据库处理数据完整性，因为这是它擅长的，让“普通”代码处理数据有效性，因为这是它擅长的。您会发现很多情况下这并不成立，并且在不同的地方做事是有意义的，所以要务实并根据具体情况进行权衡。
关于database - 数据库中应该有多少业务逻辑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1184391/