我会发挥每个系统的优势。
聚合、连接和过滤逻辑显然属于数据层。它更快,不仅因为大多数数据库引擎为此进行了 10 多年的优化,而且您可以最大限度地减少在数据库和 Web 服务器之间转移的数据。
另一方面,我使用的大多数数据库平台在处理单个值方面的功能都很差。诸如日期格式和字符串操作之类的东西在 SQL 中很糟糕,你最好在 PHP 中完成这项工作。
基本上,将每个系统用于其构建的目的。
在可维护性方面,只要清楚地区分发生在哪里,将这些划分为逻辑类型应该不会造成太大问题,当然也不足以抵消好处。在我看来,代码的清晰性和可维护性更多的是关于一致性,而不是把所有逻辑放在一个地方。
回复:具体例子...
我知道这也不是你所指的,但日期几乎是一个特例。您要确保系统生成的所有日期都是在 Web 服务器或数据库上创建的。如果数据库服务器和网络服务器曾经配置为不同的时区(我已经看到这种情况发生),否则这样做会导致一些潜在的错误。例如,想象一下,您有createdDate
一个默认值的列,该列在 DBgetDate()
插入时应用。如果您要插入一条记录,则使用PHP 中生成的日期(例如,选择在过去一小时内创建的记录,您可能无法得到您期望的结果。至于您应该在哪一层执行此操作,我倾向于使用数据库因为,如示例中所示,它允许您使用列默认值。date("Y-m-d", time() - 3600)
对于大多数应用程序,我会在 PHP 中执行此操作。结合名字和姓氏听起来很简单,直到你意识到有时你也需要称呼、头衔和中间名缩写。另外,您几乎肯定会遇到这样的情况:您想要用户的名字、姓氏以及称呼+名字+姓氏的组合。将它们连接到数据库端意味着您最终会移动更多数据,尽管实际上它非常小。
依靠。如上所述,如果您想单独使用它们,最好在性能方面将它们单独拉出并在需要时连接起来。也就是说,除非您处理的数据集很大,否则可能还有其他因素(如您提到的可维护性)具有更大的影响。
一些经验法则:
- 生成增量 ID 应该发生在数据库中。
- 就个人而言,我喜欢数据库应用的默认设置。
- 选择时,任何减少记录数量的事情都应该由数据库完成。
- 做一些减少数据集 DB 端大小的事情通常是件好事(比如上面的字符串示例)。
- 正如你所说;排序、聚合、子查询、连接等应始终在数据库端。
- 此外,我们还没有讨论过它们,但触发器通常是不好的/必要的。
您在这里面临一些核心权衡,而平衡实际上取决于您的应用程序。
有些事情绝对应该——每次——总是在 SQL 中完成。排除大量 SQL 任务的一些例外情况(如日期的事情)可能非常笨拙,并且可能会让您在逻辑上陷入困境。在您的代码库中搜索对特定列(例如)的引用时,很容易错过视图或存储过程中包含的那些。
性能始终是一个考虑因素,但取决于您的应用程序和具体示例,可能不是一个大问题。您对可维护性的担忧可能非常有效,并且我提到的一些性能优势非常轻微,因此请注意过早的优化。
此外,如果其他系统直接访问数据库(例如,用于报告或导入/导出),您将从数据库中的更多逻辑中受益。例如,如果您想直接从另一个数据源导入用户,则可以在 SQL 中实现诸如电子邮件验证功能之类的可重用功能。
简短的回答:这取决于。:)