Modèles / stratégies de conception pour les champs personnalisés et les types de données

12

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.

design-patterns database-design

— GSto
source

6

Vous pourriez être intéressé par la lecture de certaines des réponses à cette question sur la conception d'une base de données pour les champs définis par l'utilisateur

— Rachel

À noter: Oracle va poursuivre le pantalon de tous ceux qui implémentent cela d'une manière particulière (d'après ce que je comprends, commun). Je voudrais également jeter un coup d'œil à cela.

— Steven Evers

6

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

— Doc Brown
source

4

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.

— Oded
source

J'ai également entendu parler de personnes utilisant des bases de données orientées documents comme alternative à l'EAV, mais je n'ai aucune expérience personnelle avec une telle approche.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner - C'est ce que je faisais allusion, mais comme vous-même, aucune expérience personnelle.

— Odé

4

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.

— HLGEM
source

1

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.

— JeffO
source