Comment pouvons-nous concevoir une base de données EAV pour une gestion efficace des données historiques avec différenciation des attributs ?

Une base de données EAV conçue pour gérer les données historiques avec des différences d'attributs

Présentation

La base de données Entity-Attribute-Value (EAV) a été critiquée pour ses limites, notamment en termes de conception inefficace et de problèmes de reporting. En séparant les attributs d'entité en fonction du type, ces inconvénients peuvent être surmontés tout en conservant les avantages du suivi des données historiques EAV.

Conception de modèles de SGBDR

Le schéma proposé introduit une table d'attributs principale qui catégorise les attributs de chaque type d'entité. Cela permet le traitement d'une variété de types d'attributs, notamment les options, les entiers, les dates, les chaînes, le texte et les décimales.

<code>entity_type {
    id,
    type,       // 例如，“博客”、“用户”、“产品”等
    created_at
}

entity {
    id,
    entity_type_id, 
    created_at
}

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

        option {
            id,
            attr_id,
            entity_id,
            multiple, // 允许多个值？
            name,
            created_at
        }

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

        attr_int {
            attr_id,
            entity_id,
            int,
            created_at
        }

        attr_relation {
            attr_id,
            entity_id,
            entity_fk_id,
            created_at
        }

        attr_datetime {
            attr_id,
            entity_id,
            datetime,
            created_at
        }

        attr_string {
            attr_id,
            entity_id,
            var_char,
            created_at
        }

        attr_text {
            attr_id,
            entity_id,
            text,
            created_at
        }

        attr_decimal {
            attr_id,
            entity_id,
            decimal,
            created_at
        }</code>

Exemple de requête

• Récupérer le type d'entité :

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

• Obtenir les attributs de l'entité :

  <code>  SELECT * FROM attr WHERE entity_id = ?</code>

• Récupérer la valeur de l'attribut :

  <code>  SELECT * FROM attr_option, attr_int, attr_relation, attr_text, ... WHERE entity_id = ?</code>

• Trouver des relations entre entités :

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

Problèmes potentiels

Bien qu'il s'agisse d'une amélioration par rapport aux capacités de conception EAV traditionnelles, il reste encore certains problèmes potentiels à prendre en compte :

• Plusieurs requêtes sont toujours nécessaires pour récupérer les données complètes.
• Maintenir l’intégrité des relations et des métadonnées peut être un défi.
• L'optimisation des performances nécessite une indexation et une organisation minutieuses des données.

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!