変更された EAV スキーマはどのようにして履歴データを効果的に管理できるのでしょうか?

変更された EAV データベース設計による履歴データの効果的な管理

はじめに

EAV (エンティティ-属性-値) データベースは設計上の欠陥により批判にさらされることがよくありますが、適切に構造化された EAV スキーマは、履歴データを追跡し、SQL とキーと値のシステム間のデータ交換を合理化するための実用的なソリューションを提供します。

履歴データ管理のための拡張 EAV スキーマ

一般的な EAV の制限を克服し、履歴データの処理を最適化するために、変更されたスキーマが提案されています。このアプローチでは、エンティティ属性をタイプごとに分類し、特定の属性データの効率的な保存とインデックス作成を可能にします。

データベーススキーマ

スキーマは複数のテーブルで構成されます:

• entity_type: 基本エンティティ タイプ (「製品」、「ユーザー」など) を格納します。

• entity: エンティティを対応するエンティティ タイプにリンクします。

• attr: メタデータ (名前、タイプ) を使用してエンティティ属性を定義します。

• attr_option, option: オプションベースの属性とその値を処理します。

• attr_int, attr_datetime, ...: 個別の属性タイプ (整数、日時など) の専用テーブル。

• attr_relation: エンティティ間の外部キー関係を管理します。

クエリの例

次の SQL クエリはデータの取得を示しています:

• エンティティ タイプの取得:

    SELECT * FROM entity_type et LEFT JOIN entity e ON e.entity_type_id = et.id WHERE e.id = ?

• エンティティ属性の取得:

    SELECT * FROM attr WHERE entity_id = ?

• 最新の属性値の取得:

    SELECT * FROM attr_option WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1  -- For single-value attributes
    SELECT * FROM attr_int WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1   -- For integer attributes
    SELECT * FROM attr_relation WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1 -- For relational attributes
    ...

• エンティティ関係の取得:

    SELECT * FROM entity AS e
    LEFT JOIN attr_relation AS ar ON ar.entity_id = e.id
    WHERE ar.entity_id = 34 AND e.entity_type = 2;

潜在的な課題

改善はあったものの、この修正された EAV アプローチにはいくつかの課題があります。

• パフォーマンス: 属性値の取得には複数のクエリが必要になる場合があり、パフォーマンスに影響を与える可能性があります。
• メンテナンス: 個別のテーブル間でさまざまな属性タイプを管理すると、メンテナンスがさらに複雑になります。
• カスタマイズ: 結合や集計などの高度な操作には、カスタム コードの開発が必要になる場合があります。

以上が変更された EAV スキーマはどのようにして履歴データを効果的に管理できるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。