内容:
我们有一个PHP / MySQL应用程序。 计算的某些部分直接在SQL中完成。例如:最近24小时内创建的所有用户都将通过SQL查询返回(NOW()– 1天) 我和其他开发人员之间正在进行辩论,我认为我们应该这样做:
A.将所有计算/代码/逻辑保存在PHP中,并将MySQL视为“愚蠢的”信息存储库
他的意见:
B.根据更简单/更快的方式进行混合搭配。http://www.onextrapixel.com/2010/06/23/mysql-has-functions-part-5-php-vs-mysql-performance/
我正在研究可维护性的观点。他正在研究速度(如本文所指出,MySQL中的某些操作更快)。
@ bob-the-destroyer @tekretic @OMG小马@mu太短@Tudor Constantin @tandu @Harley
我同意(并且很显然)高效的WHERE子句属于SQL级别。但是,类似这样的示例呢?
使用NOW()-SQL中的1天来选择过去24小时内创建的所有用户来计算24个期间? 返回所有用户的大写名字和姓氏? 连接字符串? (想法,伙计?) 清除属于SQL域的示例:
具体的WHERE选择 嵌套SQL语句 订购/排序 选择DISTINCT项目 计算行/项目
我会发挥每个系统的优势。
聚合,联接和过滤逻辑显然属于数据层。它的速度更快,这不仅是因为大多数数据库引擎为此进行了10多年的优化,而且还可以最大程度地减少数据库和Web服务器之间转移的数据。
另一方面,我使用的大多数数据库平台在处理单个值时的功能都很差。日期格式和字符串操作之类的东西在SQL中很烂,最好在PHP中完成。
基本上,使用每个系统来完成其工作。
在可维护性方面,只要清楚区分发生在何处,将它们与逻辑类型分开就不会造成太大问题,当然也不足以抵消收益。在我看来,代码的清晰度和可维护性更多的是一致性,而不是将所有逻辑放在一个地方。
回复:具体例子...
我知道这也不是您所指的,但日期几乎是一种特殊情况。您要确保系统生成的所有日期都在Web服务器或数据库上创建。如果将db服务器和Web服务器配置为不同的时区,则否则会导致一些隐患(我已经看到了这种情况)。想象一下,例如,您createdDate有一个默认值为DB的列getDate()应用于DB。如果您要插入一条记录,那么使用PHP中生成的日期(例如date("Y-m-d", time() - 3600),选择在过去一小时内创建的记录,您可能无法获得期望的结果。对于您应该在哪一层上执行此操作,我希望使用DB例如,它使您可以使用列默认值。
对于大多数应用程序,我会在PHP中执行此操作。混合姓氏和名字听起来很简单,直到您意识到有时也需要在其中使用称呼,标题和中间缩写。另外,您几乎肯定会以想要用户的名字,姓氏和组合称呼+姓氏+姓氏为最终结果。将它们串联在DB端意味着您最终将移动更多的数据,尽管实际上,它很小。
依靠。如上所述,如果您想单独使用它们,则最好从性能角度考虑,将它们分别拉出并在需要时进行连接。也就是说,除非您要处理的数据集庞大,否则可能还有其他因素(如您提到的可维护性)具有更大的影响力。
一些经验法则:
生成增量ID应该在数据库中进行。 就个人而言,我喜欢数据库所应用的默认设置。 选择时,任何减少记录数量的操作都应由数据库来完成。 这样做通常可以减少数据集DB端的大小(例如上面的字符串示例)。 正如你所说;排序,聚合,子查询,联接等应始终在DB端。 另外,我们还没有讨论它们,但是触发器通常是坏的/必要的。 在这里您需要面对一些核心的权衡,而平衡实际上取决于您的应用程序。
有些事情绝对应该总是在SQL中完成。排除许多任务的某些异常(如日期事件),SQL可能很笨拙,并且可能使您陷入逻辑混乱的境地。例如,在代码库中搜索对特定列的引用时,很容易错过视图或存储过程中包含的内容。
性能始终是一个考虑因素,但取决于您的应用程序和特定示例,可能并不是一个大问题。您对可维护性的担忧可能非常有效,而我提到的一些性能优势却很少,因此请提防过早优化。
另外,如果其他系统正在直接访问数据库(例如,用于报告或导入/导出),您将受益于数据库中更多的逻辑。例如,如果要直接从另一个数据源导入用户,则可以在SQL中实现类似电子邮件验证功能的重用。
简短的答案:这取决于。:)来源:stack overflow
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。