1-n 関係がエンティティ構成ではなく厳密にデータ構成である場合、隣接するテーブルの完全な ORM 表現は必要ありません。
cms/page
多くの場合、コア コードでインスピレーションや例を見つけるのは良いことです。そのため、およびcms/block
エンティティ、特にリソース モデルを参照してください。Mage_Cms_Model_Resource_Page::_getLoadSelect()
このメソッドは、データをロードするためにリソース モデルによって呼び出されるため、例として次のメソッドを取り上げます。
protected function _getLoadSelect($field, $value, $object)
{
$select = parent::_getLoadSelect($field, $value, $object);
$storeId = $object->getStoreId();
if ($storeId) {
$select->join(
array('cps' => $this->getTable('cms/page_store')),
$this->getMainTable().'.page_id = `cps`.page_id'
)
->where('is_active=1 AND `cps`.store_id IN (' . Mage_Core_Model_App::ADMIN_STORE_ID . ', ?) ', $storeId)
->order('store_id DESC')
->limit(1);
}
return $select;
}
結合に注意してください。それぞれに 1 つのエンティティ テーブル (cms_page
およびcms_block
) があることに注意してください。ちなみに、これは ORM が期待するものですが、cms-entity-to-store データを含む追加のテーブルがあります。(cms_page_store
およびcms_block_store
)。後者の 2 つのテーブルのレコードは、独自の ORM クラスによって表されるのではなく、cms/page
およびcms/block
モデルのリソース クラスによってロードのために更新、削除、または結合されます。
繰り返しになりますが、指定された ORM クラスを介して SQL を処理するかどうかの決定要因は、ビジネス ドメインに由来します。「多くの」テーブルのレコードが、ビジネス ドメインでプレゼンテーションまたは複雑な表現を必要とするものを表している場合は、ORM を介してそれらにアクセスします。