我读到过(在所有条件相同的情况下)PHP 在算术和字符串操作方面通常比 MySQL 快。在这种情况下，在请求数据库执行的操作与 Web 服务器执行的操作之间划清界线在哪里？我们专门使用存储过程作为我们的数据访问层。我的不成文规则一直是将输出格式(包括字符串操作和算术)留给 Web 服务器。所以我们的查询返回:
- 未格式化的日期
- 空值
- 没有计算值(即返回“foo”和“bar”列的值，如果需要显示值 foobar，则让网络服务器计算 foo*bar)
- 没有减少子字符串的字段(除非缩短的字段非常短，以至于我们想在数据库级别执行它以减少结果集的大小)
- 两个单独的列让前端根据需要输出
我感兴趣的是关于这是否通常是一种合适的方法或其他人是否知道有理由将这些事件推送到数据库的令人信服的性能/可维护性考虑因素的反馈。
注意:我有意将这个问题标记为与 dbms 无关，因为我相信这是一个架构考虑因素，无论一个人的特定 dbms 是什么。
最佳答案
我会划定某些层如何轮换到其他实现的位置。您很可能永远不会使用不同的 RDBMS 或拥有您网站的移动版本，但您永远不会知道。
数据点越正交，它就越接近于以该形式从数据库中释放。如果在您网站的每个理论版本上，您的值 A 和 B 都呈现为 A * B，那么您的数据库应该将其作为 A * B 返回，并且永远不会计算客户端。
假设您有一些像日期这样格式繁重的东西。有时您有短日期、长日期、英文日期...应该从数据库返回一种纯形式，然后应该用 PHP 格式化。
因此正交点也可以反向工作。数据点在其表示/显示中越动态，就越应该在客户端处理。如果字符串 A 始终被视为前六个字符的子字符串，则将其作为预子字符串从数据库中返回。如果子字符串的长度取决于某些因素，例如移动设备为 6 个，Web 应用程序为 10 个，则从数据库返回较大的字符串并在运行时使用 PHP 对其进行格式化。
关于sql - 输出格式化的数据库与前端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1171765/