Quels sont les modèles de conception à l'appui de champs personnalisés dans une application?

Nous développons une application commerciale. Nos clients demandent des champs personnalisés de soutien. Par exemple, ils veulent ajouter un champ dans le formulaire Client.

Ce que sont connus les modèles de conception pour stocker les valeurs de champ et les méta-données sur les champs?

Je vois ces options pour l'instant:

Option 1: Ajouter Champ1, Champ2, Champ3, Field4 les colonnes de type varchar à ma table Client.

Option 2: Ajouter une seule colonne de type XML dans la table client et stocker les champs personnalisés' valeurs dans xml.

Option 3: Ajouter un CustomerCustomFieldValue table avec une colonne de type varchar et de stocker des valeurs dans cette colonne. Cette table aurait également un code client, un CustomFieldID.

CustomerID,  CustomFieldID, Value
10001,       1001,          '02/12/2009 8:00 AM'
10001,       1002,          '18.26'
10002,       1001,          '01/12/2009 8:00 AM'
10002,       1002,          '50.26'

CustomFieldID serait un ID d'une autre table appelée Personnalisé avec ces colonnes: CustomFieldID, FieldName, FieldValueTypeID.

Option 4: Ajouter un CustomerCustomFieldValue tableau avec une colonne pour chaque type de valeur et de stocker des valeurs dans la colonne de droite. Semblable au n ° 3, mais les valeurs de champ sont stockées à l'aide d'une forte colonne type.

CustomerID,  CustomFieldID, DateValue,           StringValue,       NumericValue                 
10001,       1001,          02/12/2009 8:00 AM,  null,              null
10001,       1002,          null,                null,              18.26
10002,       1001,          01/12/2009 8:00 AM,  null,              null
10002,       1002,          null,                null,              50.26

Option 5: Options 3 et 4, utiliser un tableau spécifique à un seul concept (le Client). Nos clients demandent champ personnalisé dans d'autres formes. Devrions-nous plutôt nous disposons d'un système à l'échelle de champ personnalisé système de stockage? Donc au lieu d'avoir plusieurs tables comme CustomerCustomFieldValue, EmployeeCustomFieldValue, InvoiceCustomFieldValue, nous aurions une seule table nommée CustomFieldValue? Bien qu'il semble plus élégant de moi, ne serait-ce pas provoquer un goulot d'étranglement des performances?

Avez-vous utilisé l'un de ces approches? Avez-vous réussi? Quelle est l'approche qui choisiriez-vous?
Connaissez-vous une autre approche que je dois prendre en compte?

Aussi, mes clients veulent le champ personnalisé pour être en mesure de se référer à des données d'autres tables. Par exemple, un client peut vouloir ajouter un "moyen de Paiement Préféré" pour le Client. Les méthodes de paiement sont définis ailleurs dans le système. Qu'apporte le thème de la "clés étrangères" dans l'image. Devrais-je essayer de créer des contraintes pour assurer que les valeurs stockées dans le champ personnalisé tableaux sont des valeurs valides?

Grâce

======================

MODIFIER 07-27-2009:

Merci pour vos réponses. Il semble que la liste des approches est très complète. J'ai choisi l'option 2 (une seule colonne XML). Il était le plus facile à mettre en œuvre pour l'instant. Je vais probablement avoir à lunette à un plus fortement défini par l'approche de mes exigences deviennent plus complexes et que le nombre de champs personnalisés de soutien va s'agrandir.

  • Une extension de l'option 2 est la sérialisation binaire au lieu de XML. Comme vous l'avez demandé à ce que les modèles de conception sont là - Martin Fowler appelle cette Sérialisé LOB dans son livre Patterns d'Architecture d'Applications d'Entreprise - voir martinfowler.com/eaaCatalog/serializedLOB.html
  • Je suis curieux de connaître le résultat de votre démarche choisie: avez-vous été en mesure d'effectuer le tri/recherche/filtrage sur les champs personnalisés à l'aide de XML (ou sérialisé LOB)? Était-ce suffisant pour vos besoins de stockage de données ou avez-vous dû prendre un autre itinéraire? Il serait génial si vous pouviez partager les connaissances.
  • Vous n'avez pas de décrire comment le consommateur va utiliser ces données, et qui est un facteur important pour le choix de la solution de conception.
  • Comment ce travail pour vous à la fin? Je me trouve face au même problème et de l'information sur le web semble éparses au mieux.
  • L'option la plus simple (une colonne XML dans chaque tableau) s'est avéré bon. 7 ans plus tard, nous sommes sur le point de changer le design. Nous allons avec des temps d'exécution de la modification du schéma. Lorsqu'un client ajoute un champ, nous avons créer une nouvelle colonne dans la base de données à la volée, avec le bon type de données et le bon de clé étrangère pour les autres tables. Les principales raisons de ce changement: les types (intégrité des données), les clés étrangères (intégrité des données), la performance (index), la clarté (de l'interrogation et de scripts de migration est plus facile à écrire). XML a été facile à mettre en œuvre et nous a bien servi; c'est une option viable.
InformationsquelleAutor Sylvain | 2009-07-14