我对 PHP 比较陌生，但在具有 SOA 架构和多层应用程序的复杂企业环境中经验丰富的 Java 程序员。在那里，我们通常会在中间层实现具有业务逻辑的业务应用程序。
我正在编写一个替代货币系统，该系统应该易于个人和社区部署和定制；它将是开源的。这就是为什么 php/mysql 似乎是我的最佳选择。
用户有账户，他们得到余额。此外，系统根据提供的总服务和总可用资产计算价格。
这意味着，在购买时会发生一系列计算；余额和总数得到更新；这些是派生的数字，通常不会放入数据库中。
尽管如此，我还是将触发器和存储过程放入数据库中，因此在 php 代码中没有进行这些更新。
人们怎么想？这是一个好方法吗？我的经验告诉我，这不是最好的解决方案，并促使我实施中间层。但是，我什至不知道该怎么做。另一方面，到目前为止，我所拥有的 store procs 对我来说似乎是最合适的。
我希望我把我的问题说清楚了。所有评论表示赞赏。可能没有“完美”的解决方案。
正如当今的趋势一样，远离数据库通常是一件好事。您可以更轻松地进行版本控制，并且只需使用一种语言即可工作。不仅如此，我觉得存储过程是一条很难走的路。另一方面，如果你喜欢这些东西，并且对 MySql 中的 SP 感到满意，它们还不错，但我的感觉一直是它们更难调试且更难处理。
关于触发器问题，我不确定您的应用是否需要这样做。由于触发计算的事件是由用户调用的，因此这些事情可能在 PHP 中发生，即使用户同时被重定向到“等待”页面或另一个页面。显然，真正的触发器只能在数据库级别完成，但您可以使用每 X 秒运行一次 PHP 脚本的守护线程......不惜一切代价避免这种情况，并尝试让事件从用户端触发。
综上所述，我想为 PHP 上的数据访问层插入我最喜欢的解决方案：Doctrine。它并不完美，但 PHP 就是这样，它已经足够好了。完成您想要的大部分工作，并让您使用对象而不是数据库过程等。
关于您的标题，在 PHP 中，多层是完全可行的，但您必须这样做并尊重它们。PHP 代码可以调用其他 PHP 代码，现在（5.2+）很好地面向对象等等。请务必忽略这样一个事实，即您将看到的许多 PHP 代码完全是垃圾，甚至不使用方法，更不用说层和体面的 OO 建模了。如果您想这样做，这一切都是可能的，包括做您自己的（或使用现有的）MVC 解决方案。
将大量特性推送到数据库级别而不是数据抽象层的一个问题是，您会被锁定在 DBMS 的特性集中。开源软件通常被编写成可以与不同的数据库一起使用（当然并非总是如此）。将来您可能希望轻松移植到 postgres 或其他一些 DBMS。现在使用大量 MySQL 特定的特性会使这变得更加困难。
使用数据库服务器提供的触发器和存储过程以及其他功能绝对没有错。它工作得很好，你正在利用数据库的全部潜力，而不是简单地将它归为一个简单的数据存储。
但是，我敢肯定，对于这里的每个同意你（和我）的开发人员来说，至少有同样多的人认为完全相反并且在这方面有很好的经验。
多谢你们。
我使用数据库触发器是因为我认为这样控制事务完整性可能更容易。正如您可能意识到的那样，我是一名开发人员，也在努力掌握数据库知识。
现在，我看到了将 php 代码分布在多个层上的解决方案，不仅在逻辑上而且在物理上通过部署在不同的服务器上。
然而，在这个开发阶段，我想我会坚持我的触发器/sp 解决方案，因为这感觉不是那么错误。分布在多个层上需要我不断地重新设计我的应用程序。
此外，考虑到开源，如果有人喜欢替代货币系统，人们可能更容易根据他们的要求更改布局，而我不必担心如果人们接触 php 代码会导致计算错误。
另一方面，当然，我同意 db 的东西可能很难调试。
DB init 脚本和 php 文件一样在源代码控制中：）
再次感谢