纯SQL、Yii Active Record，还是混合使用？

Question

尝试梳理不同方法的优缺点。并非寻求意见，而是了解这些不同方法提供或限制的内容。

Yii声称使用他们的AR简化了DB编程，但我更关心将DB与我的代码“融合”得太过紧密。我显然知道它们可以一起工作，但映射有点令人担忧。我希望在DB中存在尽可能多的控件和约束，并想知道摆脱纯SQL是否会在任何方面限制性能。

- enfield

Answer 1

ActiveRecord非常适合具有相对简单ORM的系统，其中Model == Table，具有1对1关系。换句话说，如果所有数据对象都适合单个表中（可能还有一些额外的表与它们相关），那么ActiveRecord就是为您而设计的。通常情况下，您可以设计软件使其符合这种情况！

但是你是正确的，它确实在一定程度上“混合”了DB实现和代码。假设Model == Table，这意味着数据库实现与您的代码并不分离。如果您在多个表中存储复杂的Models，则ActiveRecord会出现一些问题。但这是一个相当复杂的论点，我不会进入。其他模式（如Data Mapper）可以提供更大的灵活性，但需要更多的初始编码工作。

ActiveRecords 是一种设定即可忘记的编程方式。非常容易和快速。无需繁琐编写getter和setter，只需使用从表格中构建的漂亮PHP对象。我最近使用Yii构建了一个相当大的应用程序，我喜欢ActiveRecord的速度和简单性。我现在正在使用Zend开发一个应用程序，尽管我可以看到他们的方式给你更多的控制权，但我想念AR的轻松程度。;)

- thaddeusmt

---

感谢您的补充意见。这个问题源于我正在开发一个交易处理量很大的应用程序，使用了我认为很简单的数据库设计，但其他人可能会认为它有太多表，因为它符合第六范式。看起来在接受AR作为正确方法之前需要进行更多的研究。 - enfield

Answer 2

Yii ActiveRecord无疑简化了与数据库的编程，就像任何体面的ActiveRecord实现一样。

映射到数据库

关于数据库和您的模型之间的映射，没有问题会使您的代码“接管”您的数据库。您唯一需要始终保持最新的是：

/**
 * @return string the associated database table name
 */
public function tableName()
{
    return 'my_table';
}

考虑到表名不会经常更改，这并不是一个实际的问题。

你的ActiveRecord模型中还有其他部分应该与模式保持同步：

• 描述模型类属性的phpdoc注释
• 其他公共函数，实现各种功能，例如验证规则[public function rules()]，外键模型关系[public function relations()]，属性标签[public function attributeLabels()]等。

然而，即使这些不反映当前的数据库模式，你仍然可以使用模型和数据库本身--只是相应的功能将不再起作用。

这些数据片段不会 强制执行 数据库约束，它们只是通过允许你以更直观的方式访问功能来帮助你。 实际的约束仍然在数据库中实现。

性能

Yii实现了一个查询构建器query builder，您可以使用它从流畅的表达式生成SQL（当直接查询模型时，您的模型使用相同的机制）。该构建器从流畅的表达式生成SQL，结果不会比直接执行等效的SQL更慢。

当然，使用查询构建器本身会有一些开销，但这是几乎所有现代编程语言都选择进行的权衡（LINQ将是最大的示例），因为它完全值得。

无论如何，您都可以使用 CDbCommand 自己编写SQL查询。我没有看到这样做的理由，但如果您需要，始终可以使用该选项。因此，无论您需要做什么，都不会因ActiveRecord的缺陷而被置于困境。

- Jon

---

再次感谢您的帮助。对于任何构建，我都关注所部署内容的可扩展性。也许我应该在问题中将其与性能分开。您对可扩展性有不同的看法吗？或者您认为您的答案（非常有帮助）已经涵盖了这一点？ - enfield

@longterm：可扩展性与数据库设计、服务器集群、内存缓存等有关。对于Yii或其他优秀的框架来说，这些都不是问题；它们会使用你所设置的一切。 - Jon