Existe-t-il des stratégies ou des modèles de conception communs pour concevoir des applications qui ont la possibilité d'ajouter des champs personnalisés aux objets de données ou de créer votre propre définition personnalisée des objets? Par exemple, je pense à des produits tels que SalesForce, où vous pouvez avoir vos propres types d'informations, des cadres tels que Expression Engine et la façon dont il gère les canaux et les groupes de champs de canaux (exemple) , ou comment les CMS comme Wordpress ont la capacité de ajouter des champs aux types de publication personnalisés.
12
Réponses:
Martin Fowler a donné une belle description de la façon de modéliser les propriétés dynamiques (ce qui est essentiellement ce que vous demandez) dans son livre "Patterns d'analyse" . La plupart du contenu est disponible gratuitement en ligne sous forme d'articles PDF, celui que vous recherchez est celui-ci:
http://martinfowler.com/apsupp/properties.pdf
la source
Le
EAVmodèle est normalement utilisé pour les schémas non structurés comme vous le décrivez.Il souffre des performances et de la capacité d'interroger ces propriétés dynamiques de manière ad hoc ... et en tant que tel, il est considéré par beaucoup comme un anti-modèle.
D'autres approches consistent à utiliser un format dynamique tel que XML ou Json pour conserver ces propriétés, éventuellement avec un stockage dédié pour chaque propriété pour faciliter la recherche.
la source
En plus de la table EAV décrite par @Oded, les gens utilisent la base de données nosql pour ce type d'informations. N'oubliez pas qu'il n'y a aucune raison pour laquelle votre application ne peut pas utiliser une base de données relationnelle pour les parties qui ont du sens avec le modèle relationnel et une base de données nosql pour les informations qui ne le font pas.
Une troisième possibilité consiste à ajouter plusieurs colonnes pour les champs ajoutés par le client (Customerfield1, customerfield2, etc.), puis à demander au client de définir ce qu'ils signifient. Cela ne fonctionne que pour le nombre de champs configurables par le client que vous ajoutez, donc c'est bien si vous vous attendez à ce qu'ils en aient besoin de deux ou trois mais ne fonctionneront pas du tout si vous en aurez besoin de centaines.
la source
Vous n'auriez pas la première application qui avait une table avec: UDF1, UDF2, UDF3 ... Les autres suggestions (EVA ou NoSQL) sont bien meilleures.
Selon le SGBDR ( SQL Server le propose ), vous pouvez sortir de la normalisation et avoir un champ qui contient les données au format XML ou simplement en texte brut. Vous devrez vous fier au code pour gérer cela.
la source