修改後的EAV Schema如何有效管理歷史資料？

透過修改後的 EAV 資料庫設計有效管理歷史資料

簡介

雖然 EAV（實體-屬性-值）資料庫經常因設計缺陷而受到批評，但結構良好的 EAV 模式為追蹤歷史資料並簡化 SQL 和鍵值系統之間的資料交換提供了實用的解決方案。

用於歷史資料管理的增強型 EAV 架構

為了克服常見的 EAV 限制並優化歷史資料處理，提出了一種修改後的模式。這種方法按類型對實體屬性進行分類，從而實現特定屬性資料的高效儲存和索引。

資料庫架構

此架構包含多個表：

• entity_type： 儲存基本實體類型（例如「產品」、「使用者」）。

• 實體：將實體連結到其對應的實體類型。

• attr: 使用元資料（名稱、型別）定義實體屬性。

• attr_option, option: 處理基於選項的屬性及其值。

• attr_int、attr_datetime、...: 不同屬性類型（整數、日期時間等）的專用表。

• attr_relation：管理實體之間的外鍵關係。

範例查詢

以下 SQL 查詢說明了資料檢索：

• 擷取實體類型：

  <code class="language-sql">  SELECT * FROM entity_type et LEFT JOIN entity e ON e.entity_type_id = et.id WHERE e.id = ?</code>

• 擷取實體屬性：

  <code class="language-sql">  SELECT * FROM attr WHERE entity_id = ?</code>

• 擷取最近的屬性值：

  <code class="language-sql">  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
    ...</code>

• 擷取實體關係：

  <code class="language-sql">  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;</code>

潛在挑戰

儘管有所改進，這種修改後的 EAV 方法仍面臨一些挑戰：

• 效能：檢索屬性值可能需要多個查詢，可能會影響效能。
• 維護：跨單獨表管理各種屬性類型會增加維護複雜度。
• 自訂：進階操作，例如聯結或聚合，可能需要自訂程式碼開發。

以上是修改後的EAV Schema如何有效管理歷史資料？的詳細內容。更多資訊請關注PHP中文網其他相關文章！