La conception de bases de données EAV est-elle la bonne solution pour une gestion efficace des données historiques ?

Conception de base de données EAV : une approche de gestion des données historiques

Le modèle de base de données Entité-Attribut-Valeur (EAV), bien que souvent critiqué pour ses problèmes potentiels d'intégrité des données et de reporting, offre des avantages dans le suivi des données historiques et dans la liaison entre les environnements SQL et les environnements de magasin de valeurs-clés. Cet article explore une approche EAV raffinée pour atténuer ces problèmes.

Organisation des attributs d'entité par type de données

Une amélioration clé de l'EAV traditionnel est la ségrégation des attributs d'entité en fonction de leurs types de données. Cela facilite la gestion des relations (par exemple, "belongsTo", "has", "hasMany", "hasManyThrough") et permet une indexation appropriée des attributs et des entités.

Schéma relationnel proposé

Le schéma de base de données relationnelle suivant est proposé :

<code class="language-sql">entity_type {
    id,
    type,       -- e.g., "product," "user"
    created_at
}

entity {
    id,
    entity_type_id,
    created_at
}

attr {
    id,
    entity_id,
    type,
    name,
    created_at
}

option {
    id,
    attr_id,
    entity_id,
    multiple, -- Allow multiple values
    name,
    created_at
}

attr_option {
    id,
    attr_id,
    entity_id,
    option_id,
    option,
    created_at
}

-- Additional tables for various attribute types (e.g., attr_int, attr_datetime)</code>

Suivi des données historiques

Ce schéma permet le suivi des données historiques en ajoutant de nouvelles valeurs d'attribut et en tirant parti des horodatages pour identifier les dernières modifications. Cela évite le besoin de mises à jour des données tout en préservant un historique complet des modifications.

Exemples de requêtes

Des requêtes illustratives démontrent la récupération de données :

• Récupération du type d'entité :

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

• Récupération des attributs d'entité :

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

• Récupération de valeur d'attribut (valeurs simples et multiples) :

  <code class="language-sql">  SELECT * FROM attr_option WHERE entity_id = ? AND multiple = 0 ORDER BY created_at DESC LIMIT 1  -- Single Value
    SELECT * FROM attr_int WHERE entity_id = ? ORDER BY created_at DESC LIMIT 1                  -- Integer Value
    -- ... other attribute type queries</code>

• Récupération de relation :

  <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>

Défis et considérations

Malgré ses avantages, cette approche présente certains défis :

• Complexité des requêtes : Plusieurs requêtes peuvent être nécessaires, similaires aux interactions clé-valeur du magasin.
• Optimisation des performances : Les stratégies d'optimisation peuvent être complexes.
• Gestion des relations : Les relations doivent être explicitement définies et gérées par programme, même dans un contexte relationnel.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!