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

Question

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.

Quelles sont les connu des 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?

Merci

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

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

Answer 1

Je suis d'accord avec les affiches ci-dessous que les Options 3, 4, ou 5 sont les plus susceptibles d'être appropriées. Cependant, chacun de vos implémentations a ses avantages et des coûts. Je vous suggère de choisir un par correspondant à vos besoins spécifiques. Par exemple:

1. Option 1: avantages: Rapide à mettre en œuvre. Permet DB actions sur les champs personnalisés (recherche, tri).
   Option 1 contre: les champs Personnalisés sont génériques, donc pas fortement typé champs. Table de base de données est inefficace, taille-sage avec de nombreux étrangers champs qui ne seront jamais utilisés. Nombre de champs personnalisés permis doit être prévu.
2. Option 2 avantages: Rapide à mettre en œuvre. Flexible, permettant arbitraire le nombre et le type des champs personnalisés.
   Option 2 inconvénients: Pas de DB actions possibles sur les champs personnalisés. C'est mieux si tout ce que vous devez faire, c'est afficher les champs personnalisés, plus tard, ou de faire des manipulations mineures des données uniquement sur une base Client.
3. Option 3 avantages: à la Fois souple et efficace. DB actions peuvent être effectuées, mais les données sont normalisées quelque peu afin de réduire le gaspillage de l'espace. Je suis d'accord avec l'inconnu (google) la suggestion que vous ajoutez une colonne supplémentaire qui peut être utilisé pour spécifier le type ou la source de l'information. Option 3 contre: Légère augmentation du temps de développement et la complexité de vos requêtes, mais il n'y a pas trop d'inconvénients, ici.
4. L'Option 4 est la même que l'Option 3, à l'exception de vos données typées peuvent être opérés au niveau de DB. L'ajout d'informations de type de la table de lien dans l'Option 3, il permet de faire plus d'opérations à notre niveau de l'application, mais la bd ne sera pas en mesure de faire des comparaisons ou de tri, par exemple. Le choix entre le 3 et le 4 dépend de cette exigence.
5. Option 5 est la même que 3 ou 4, mais avec encore plus de flexibilité pour appliquer la solution à beaucoup de différentes tables. Le coût dans ce cas, la taille de ce tableau va croître beaucoup plus grande. Si vous faites beaucoup de coûteuses opérations de jointure pour arriver à vos champs personnalisés, cette solution peut ne pas l'échelle.

P. S. Comme indiqué ci-dessous, le terme "modèle de conception" se réfère généralement à la programmation orientée objet. Vous êtes à la recherche d'une solution à un problème de conception de base de données, ce qui signifie que la plupart des conseils sur les modèles de conception ne sera pas applicable.

Answer 2

Aussi loin que le code de l'application, je n'en suis pas sûr. Je sais que les champs personnalisés grandement bénéficier d'une VAE modèle dans la base de données.

Par les commentaires ci-dessous, la plus grande erreur que vous pouvez faire avec ce modèle est de mettre les clés étrangères. Jamais, jamais, jamais mettre quelque chose comme FriendID ou TypeID dans ce modèle. L'utilisation de ce modèle en collaboration avec la typique du modèle relationnel et de garder les champs de clé étrangère dans les colonnes de table comme ils le devraient.

Une deuxième erreur est de placer les données dans ce modèle qui doit être déclarée avec chaque élément. Par exemple de mettre quelque chose comme nom d'utilisateur dans ce modèle signifie que chaque fois que vous souhaitez accéder à un utilisateur et le besoin de connaître son nom d'utilisateur que vous avez commis-vous à une jointure, au mieux, ou 2n requêtes où n est le nombre d'utilisateurs vous êtes en train de regarder. Quand vous considérez que vous êtes généralement besoin de l'Identifiant de propriété pour chaque Utilisateur de l'élément, il devient évident que cela devrait rester dans les colonnes de la table.

Toutefois, si vous êtes simplement à l'aide de ce modèle avec les champs utilisateurs personnalisés, vous serez bien. Je ne peux pas imaginer de nombreuses situations où un utilisateur serait d'entrer dans les données relationnelles et l'EAV modèle n'est pas trop significativement négatif pour les recherches.

Enfin, n'essayez pas de joindre les données à partir de cela et d'obtenir un joli joli jeu d'enregistrements. Prenez l'original et puis, prenez l'ensemble des enregistrements de l'entité. Si vous trouvez vous-même tentés de rejoindre les tables que vous avez probablement fait la deuxième erreur comme mentionné ci-dessus.

Answer 3

Si vous êtes en développement avec un langage orienté objet, nous parlons adaptative modèles d'objet ici. Il ya tout à fait quelques articles écrits au sujet de la façon dont vous pouvez mettre en œuvre dans oo-langues, mais pas tellement d'informations sur la façon de concevoir la banque de données secondaires.

Dans la société où je travaille, nous avons résolu le problème en utilisant une base de données relationnelle pour stocker la COMPOSANTE de gestion des données. Nous avons entité centrale de la table pour la présentation de toutes les différentes "entités" dans le domaine, comme les gens, les périphériques réseau, les entreprises, etc... Nous entreposer des "champs de formulaire" à des tableaux de données sont typées, nous avons donc d'un tableau de chaînes, une pour les dates et ainsi de suite. Tous les tableaux de données ont une clé étrangère pointant vers la table d'entité. Nous avons aussi besoin de tables pour présenter le type du côté, c'est à dire ce genre d'attributs (champs de formulaire) peut certaine entité et cette information est utilisée pour interpréter les données dans les tables de données.

Avantages de notre solution sont que tout ce qui peut être modélisé sans modification du code, y compris les références entre les entités, multivalues et ainsi de suite. Il est également possible d'ajouter des règles de gestion et des validations sur les champs et ils peuvent être réutilisés dans toute forme. Les inconvénients sont que le modèle de programmation n'est pas très facile à comprendre et les performances de la requête sera pire qu'avec plus de DB typique de la conception. Une autre solution de base de données relationnelle aurait pu être mieux et plus facile pour la CG.

La construction d'une bonne CG avec une banque de données car c'est beaucoup de travail et je ne le recommande pas si vous n'avez pas hautement qualifiés développeurs. Peut-être qu'un jour il y aura un OS solution pour ces types d'exigences.

Champs personnalisés ont été discutées avant dans la:

• Comment voulez-vous créer et de stocker personnalisés définis par l'utilisateur des champs dans une base de données SQL?
• Pour ajouter personnalisé/champs définis par l'utilisateur fonction ou pas?
• Quelle architecture puis-je utiliser pour gérer un panier où chaque produit nécessite différents attributs pour être sauvé

Answer 4

Option 4 ou 5 serait mon choix. Si vos données est important, je n'irais pas jeter aux orties vos informations de type à l'Option 3. (Vous pourriez essayer de mettre en œuvre complète de la vérification de type vous-même, mais c'est un assez gros travail, et le moteur de base de données déjà fait pour vous.)

Quelques réflexions:

• Assurez-vous que votre CustomFields a DataTypecolonne.
  • Utiliser un fichier UDF à base de vérification de la contrainte sur CustomFieldValues pour s'assurer que la colonne spécifié par CustomFields.DataType est non-nulle.
  • Vous aurez également besoin d'une norme contrainte de vérification pour vous assurer que vous avez exactement une valeur non null.
• Concernant les clés étrangères, je voudrais modéliser ces séparée, DataType.
  • Chaque potentiel de la croix-table de référence aurait besoin de sa propre colonne. C'est bon, parce qu'il maintient l'intégrité référentielle.
  • Vous avez à l'appui de ces relations dans le code de l'application, de toute façon, donc le fait qu'ils sont codés en dur dans la base de données n'est pas réellement limiter la fonctionnalité.
  • Cela permettra également de jive bien avec votre ORM, si vous en utilisez un.
• Pour l'Option 5, l'utilisation intermédiaire de tables pour modéliser les relations.
  • Vous auriez encore un CustomerCustomFieldValue, mais au lieu de cela, avec seulement CustomerID et CustomFieldValueID colonnes.
• Penser à long et dur sur vos contraintes de chaque étape de la manière. C'est délicat de trucs, et un faux pas peut entraîner totale havok en bas de la ligne.

Je me sers de ce dans une application en cours de développement. Il n'y a eu aucun problème pour le moment, mais EAV dessins encore effrayer les daylights hors de moi. Juste être prudent.

En aparté, XML peut également être un bon choix. Je ne sais pas que beaucoup à ce sujet à partir de l'expérience directe, mais elle a été l'une des options que j'ai pris en compte au début de la conception de données, et il avait l'air assez prometteur.