Yii框架中数据库访问与活动记录有何根本差异？

Yii 框架中数据库访问与活动记录的根本差异

者常见痛点

• 不清楚何时使用原生 SQL，导致代码冗余或维护困难。
• 担心 SQL 注入等安全风险，却又想较快完成增删改查。
• 在复杂查询下性能不佳，却又不想手写大量繁琐的 SQL。
• 学习成本高的观点是。既要掌握底层 DB 组件，又要熟悉 Active Record 的用法。

一、数据库访问

主要特性

• 灵活性：可以直接编写原生 SQL，支持任何复杂查询、窗口函数、临时表等高级特性。
• 高效性：省去 ORM 的映射开销，在大批量插入、复杂联表或事务处理时表现更佳。
• 底层控制：需要手动处理数据转换、验证还有错误捕获，适合对性能和细节有严格要求的场景。

常见痛点及解决思路

痛点：手写 SQL 易出现拼写错误或遗漏参数，引发 SQL 注入风险；代码可读性差，后期维护成本高。

解决：

1. 始终使用参数绑定（:param) 而非字符串拼接。
2. 将重复的查询封装为自定义方法或查询建立器类，提高可读性。
3. 配合事务（\Yii::$app->db->beginTransaction) 处理批量操作，确保数据一致性。

二、活动记录

活动记录是 Yii 实现的 ORM 技术，所有模型类均继承自 \yii\db\ActiveRecord。 怎么说呢，它把数据表映射为对象，使得“通过对象属性操作数据库”成为可能。

• 简洁易用：通过对象属性和方法完成增删改查，无需手写 SQL。
• 高级封装：提供链式查询（CActiveRecordQuery)、关联查询、延迟加载等功能，让复杂业务逻辑更直观。
• 使用较稳定：自动进行参数化查询和内置的数据验证，显著降低 SQL 注入风险。

常见痛点及应对策略

痛点：

• #1# 在大规模批量导入时性能下降，因为每条记录都会实例化对象并触发验证。怎么说呢，
• #2# 对于跨多表的大型报表。需要额外使用 Query Builder 或原生 SQL 来补足功能不足。
• #3# 当模型关系错综复杂时延迟加载可能导致 N+1 查询问题。

应对策略：

1. BULK INSERT：Pry 使用 Yii 的批量插入 API（\Yii::$app->db->createCommand->batchInsert) 替代逐条保存。
2. Eager Loading：Pry 在需要一次性获取关联数据时使用 ::with/::joinWith) 防止 N+1 查询。
> > > > > > > >
3. Mixed Approach：Pry 在报表层面混合使用 Query Builder 与 Active Record，以兼顾可读性和性能。

三、主要差异对比表

	数据库访问	活动记录

Coding Complexity 代码复杂度

- 必须自行编写完整SQL - 参数绑定需手动处理 - 对新手友好度低

- 通过属性/方法完成CRUD - 自动生成SQL并绑定参数 - 入门门槛低

Dynamism 灵活度

- 可执行任意复杂查询 - 支持存储过程/CTE/窗口函数等高级特性

- 基础查询足够日常需求 - 超出框架能力时仍需回退到原生SQL

Performance 性能

- 大批量写入/复杂联表最优 - 避免对象实例化开销

- 简单单表查询非常快 - 对象映射带来轻微额外消耗

Safety / Validation

- 手动防御SQL注入。需要自行做好过滤

- 自动参数化 + 内置验证规则

Maintainability

- 随业务增长SQL散落各处，可读性下降

- 模型统一管理字段与规则，代码更易维护

Use‑Case Fit

- 事务、大批量导入、报表/统计分析等场景

- 常规业务逻辑、页面展示、CRUD 操作

Learning Curve

。