「eav_」テーブルの目的

テーブルの意味は何だろうといつも思っていました。

eav_entity  
eav_entity_datetime
eav_entity_decimal
eav_entity_int
eav_entity_store
eav_entity_text

それらは常に空です。1.6より前のバージョンで作成されapp/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.php、後でバージョン1.6+のインストールスクリプトに引き継がれまし/app/code/core/Mage/Eav/sql/eav_setup/install-1.6.0.0.php
た。テーブルの1つにリンクされたリソースモデルMage_Eav_Model_Resource_Entity_Store（他のテーブルがある場合もあります）がありましたが、何も起こりませんでした。

これらのテーブルの使用はありますか？これは、たとえばレイアウトバージョンや管理ブレッドクラムのように開始され、実装されていない他の「機能」ですか？

私の推測では、それは一部のレガシーであり、開発者が「一般的な」エンティティ/モデルを実装するための「便利な」パターンです。

あなたが述べたように、関連するテーブルは通常空です。その理由は、コアEAVエンティティのいずれもこの「デフォルト」エンティティテーブル構造を使用していないからです。これらは、1.8インストールのエンティティテーブルです。

mysql> select distinct(entity_table) from eav_entity_type;
+-------------------------+
| entity_table            |
+-------------------------+
| customer/entity         |
| customer/address_entity |
| sales/order             |
| sales/order_entity      |
| catalog/category        |
| catalog/product         |
| sales/quote             |
| sales/quote_address     |
| sales/quote_entity      |
| sales/quote_item        |
| sales/invoice           |
+-------------------------+
11 rows in set (0.00 sec)

一例として、顧客のモデルを使用して、我々は、リソース・モデルがあることがわかりますMage_Customer_Model_Resource_Customer拡張しMage_Eav_Model_Entity_Abstract、ソースを。

注：前の1.6に顧客エンティティのリソースモデルをしてMage_Customer_Model_Entity_Customerも、拡張Mage_Eav_Model_Entity_Abstract、ソース。

私たちが調べるとMage_Eav_Model_Entity_Abstract、クラスを我々は見つけるgetEntityTable方法を。このメソッドは、一般的なCRUD操作中にクエリを構築するときに使用するテーブルを決定するために使用されます。興味深い別の方法は getValueTablePrefixです。これは、データ「タイプ」のテーブルのテーブルの接頭辞を決定し*_datetime、*_decimal、*_varcharのように。

それらのメソッドのソースを覗きます（こことここ）。

public function getEntityTable()
    {
        if (!$this->_entityTable) {
            $table = $this->getEntityType()->getEntityTable();
            if (!$table) {
                $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
            }
            $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
        }

        return $this->_entityTable;
    }

上記のメソッドでは、エンティティタイプがカスタムテーブルを定義しない場合、デフォルトでになることがわかりますMage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE。その定数の値はで'eav/entity'、これは順番にeav_entityテーブルに変換されます（アプリケーションに設定済みのテーブルプレフィックスがないと仮定します）。私が言及した2番目の方法は、指定されたエンティティに何も構成されていない場合、プレフィックスとしてこのテーブルにフォールバックします。列のeav_entity_type表の値を調べると、value_table_prefixそれらがすべてであることがわかりますNULL。

public function getValueTablePrefix()
    {
        if (!$this->_valueTablePrefix) {
            $prefix = (string)$this->getEntityType()->getValueTablePrefix();
            if (!empty($prefix)) {
                $this->_valueTablePrefix = $prefix;
                /**
                * entity type prefix include DB table name prefix
                */
                //Mage::getSingleton('core/resource')->getTableName($prefix);
            } else {
                $this->_valueTablePrefix = $this->getEntityTable();
            }
        }

        return $this->_valueTablePrefix;
    }

メソッドのロジックはかなり単純です。値のプレフィックスが定義されていない場合、エンティティテーブル名をプレフィックスとして使用します。

これらのテーブルは長い間Magentoに存在しているため、完全に削除するよりも下位互換性を保つために残しておくのがベストだと思います。私が考えていたのは、他の開発者がいくつかのクラスを拡張し、管理者によって変更できる「動的な」属性を持つことができる、使いやすいエンティティ/モデル構造でした（カタログ製品と顧客モデルを参照）。残念ながら、上記のパターンの実装と実践はうまくスケールしていないようで、問題につながります。おそらくドキュメントやサンプルユースケースの不足やパフォーマンスの低下が原因で、この構造が実際に使用されたことはありません。

私はコア開発者（または考古学者）ではありませんが、コードとデータ構造から収集したものです。

基本EAVリソースモデルのこのコードを考慮してください。

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
public function getEntityTable()
{
    if (!$this->_entityTable) {
        $table = $this->getEntityType()->getEntityTable();
        if (!$table) {
            $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
        }
        $this->_entityTable = Mage::getSingleton('core/resource')->getTableName($table);
    }

    return $this->_entityTable;
}

このメソッドは、ストレージに使用するベースエンティティテーブル名を取得します。そのため、製品のリソースモデルの場合、このメソッドは戻りますcatalog_product_entity（テーブル名のプレフィックスが設定されていない場合）

これらの4行は最も明らかです。

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
$table = $this->getEntityType()->getEntityTable();
if (!$table) {
    $table = Mage_Eav_Model_Entity::DEFAULT_ENTITY_TABLE;
}

エンティティにテーブルセットがない場合、次の定数が使用されます

#File: app/code/core/Mage/Eav/Model/Entity.php
const DEFAULT_ENTITY_TABLE      = 'eav/entity';

この eav/entity文字列は、テーブル名を検索するために使用されます

#File: app/code/core/Mage/Eav/Model/Entity/Abstract.php
Mage::getSingleton('core/resource')->getTableName($table);

configからテーブル名を取り出します。

<!-- File: app/code/core/Mage/Eav/etc/config.xml -->
<entity>
    <table>eav_entity</table>
</entity>

あぁ！eavエンティティタイプにテーブル名が設定されていない場合、Magentoはeav_entityデフォルトの保存場所としてテーブルします。

元のMagentoエンジニアリングチームはEAVコンセプトに夢中になりました。現代のMagentoはこれを縮小しましたが、EAVモデルは多くの問題の優先ソリューションでした。

初期のプレリリースEAV実装がこの中央にすべてのデータを格納していると想定/推測するのが妥当と思われるeav_entityタイプテーブル（エンタープライズプラットフォームの一般的なパターン）に、エンティティタイプが後。

もう1つの（説得力のある）可能性は、この機能が「テーブルレス」CRUDモデルを有効にすることを意図していたことです。理論的には、正しいEAVタイプ情報を挿入し、モデル/リソース/コレクションクラスを設定し、これらのeav_entityテーブルにデータを保存することが可能です。MagentoはEAVから遠ざかり、発売後はエンドユーザー機能のエンジニアリングチームに注力したため、この機能は霧の中に消えていきました。これがうまくいけば興味がありますが、多くの注目を集めているコードパスではないので、これに頼りたくはありません。TAFがその使用をカバーしているのは疑わしいです。

Magentoは、その多くの機能（顧客、製品など）に「エンティティ属性値」と呼ばれるデータモデルを使用します。これにより、オンザフライでテーブルを再構築したり変更したりすることなく、システム内の動的な属性が許可されます。ウィキペディアのEAV