php - Zend_Db_Table 加入查询 vs 数据库 View

Question

我想知道在访问数据库数据时实现一致性的最佳实践和最佳方法是什么:

当前结构如下

Data Access --> Business Logic --> Controller --> View

我的数据访问层由 Zend_Db_Table、Zend_Db_TableRowset 和每个表的 Zend_Db_TableRow 组成。

我的业务逻辑存储在基于表

命名的模型中

有问题的查询示例:

我想根据他的用户名获取特定用户。为此，我有一个 user 表和一个 role 表(role.id 在用户表)。

我不想使用 findDependentRowset 为返回的每一行运行附加查询。 (在显示数据的数据网格中会出现问题，因为可以返回很多行)。

我的选择(本例中使用getName()来简化，但可以是任何处理):

• 对用户表中的角色表进行自定义连接，返回一个由关联数组组成的索引数组。在这种情况下，我无法调用在我的 Model_DbTable_User 中定义的 getName() 函数来构建名称(名字 + 中间名 + 姓氏)。即使我将我的数组“转换”到 Zend_Db_Table_Rowset(或我的自定义 table_rowset)，我也无法访问我的自定义类方法，因为我得到了一个通用的 Zend_Db_Table_Row 对象。

• 进行自定义连接，但在运行时的查询中使用 CONCAT() 构建名称，我仍然得到一个数组，但名称是 build，所以我不需要 getName() 方法。但是，如果我有特定的逻辑要应用，我就会卡住。

• 在我的数据库中创建一个连接user 和role 表的 View ，并创建一组新的Zend_DbTable、Zend_DbTableRowset 和 Zend_DbTableRow。这样我就可以在我的数据库堆栈中拥有特定的逻辑。

• ORM(推进或学说(1 或 2))，我没有这方面的经验，我可能需要更多信息才能做出正确的选择。

我的替代目标是确保我的数据结构保持一致

即: 一路排列:

array(
    array(row1), 
    array(row2)
);

一路反对

$row = $rowset->current();
$row->field;

Answer 1

不管怎样，都应该创建一个 View ，因为它对其他想法的补充多于与它们的竞争。该 View 将:

• 将数据库抽象为您可以更轻松地使用的东西。
• 更快，因为没有解析。
• 可以在您的应用程序之外访问。

创建 View 后，您可以选择最能解决问题的策略。如果您正在创建表示单个实体的表单，那么 ORM 可能是一个不错的选择。但是，如果您要显示大量数据或生成包含许多实体的报告，那么使用 SQL 等声明性语言可能会更容易，并且性能会更好。