Propriétés spéciales de l'entité et normalisation de la base de données

Question

Supposons que j'ai un objet client qui possède toutes les propriétés standard du client (nom, adresse, contact, etc.). Nous recevons un nouveau client (Acme) qui a une demande très précise que les factures que nous lui envoyons aient notre code d'identification comme code à barres. Nous ne voulons pas cela pour tous les autres clients, nous avons donc l'intention de le faire comme un cas particulier pour Acme. Maintenant, supposons que beaucoup de clients ont ces petites demandes uniques. Quelle serait la meilleure façon en mode ces données:

Je vois des possibilités de couple et leurs avantages/compromis:

1) Hardcoded, au point de l'écart, la vérification des ID ou le nom du client. Avantages: Moins d'effort, point d'intégration unique
Compromis: code peu fiable, très sujet à l'erreur. La modification des drapeaux nécessite un nouveau déploiement. Difficile de trouver des écarts à mesure que les propriétés augmentent en nombre.

2) Colonnes DB sur le client pour chaque propriété. Les drapeaux seront mis à vrai pour le client, faux pour tout le reste. Avantage: Relativement simple, les propriétés peuvent être modifiées à la volée.
Tradeoff: rend les bases de données très larges et le schéma bâclé. À mesure que d'autres propriétés sont ajoutées, les données deviennent de plus en plus ingérables. Le code sera également bâclé car de nombreuses propriétés inutiles devront être mappées.

3) Mappage de propriétés codées en dur. Une carte qui contient des propriétés spéciales pour les clients. La carte peut ensuite être demandée pour des propriétés spéciales, et le flux de code peut sortir de là.
Avantages: Un seul point de gestion.
Inconvénient: codé en dur. Les identifiants/noms de clients figureraient dans le code. Faire des changements nécessite des déploiements.

4) Table CustomerProperty avec colonnes clé/valeur.
Avantages: Propre. Un seul point de gestion. Dynamique.
Inconvénients: Complexe relatif, comparé aux autres solutions. De toute évidence, les choix varient en fonction des circonstances. Si nous avons des centaines d'écarts, il serait important d'avoir un seul point de gestion. Si c'était vraiment une déviation unique, je pense que # 1 serait correct, quoique hackish.

J'ai mes opinions sur ce qui est mieux dans ce cas .... mais j'aimerais connaître les opinions de tout le monde.

Answer 1

Je voudrais aller avec l'option 4. De l'expérience, quand j'ai opté pour les options plus rapides, le résultat est inévitablement la mise en œuvre de la solution optimale et le hack seulement causé des problèmes. J'essaie toujours d'aborder ces problèmes d'un point de vue de domaine et dans ce cas 4 est le meilleur modèle. La différence dans la mise en œuvre est minime par rapport à la maintenance de tous les artefacts et le refactoring éventuel que vous aurez à faire.

Answer 2

Je préfère l'approche entièrement normalisée; J'aurais une table qui énumère les différentes demandes spéciales ponctuelles, avec sa clé primaire. Ensuite, j'ai une table de jointure qui a deux colonnes, les deux clés étrangères, avec la première colonne l'identifiant du client, et la deuxième colonne l'identifiant de la table des demandes spéciales.

Answer 3

Je fait beaucoup de 1) sur un projet précédent de la mine, et finalement transférés à une solution comme le numéro 4). J'ai utilisé l'emplacement de mes hacks pour placer des crochets pour la personnalisation. C'était certainement plus facile à gérer, d'autant plus que les demandes de personnalisation augmentaient.Je pensais initialement que 2) fonctionnerait pour votre scénario particulier (ne tenant pas compte des demandes de personnalisation supplémentaires supposées, juste la demande de code à barres), parce que je supposais que d'autres clients pourraient également vouloir un code à barres sur leurs factures. Cependant, je pourrais aussi les voir vouloir les informations codées sous un format différent de celui que vous avez initialement conçu pour le premier client, ce qui pourrait potentiellement conduire au problème que vous avez commencé.

Je dis donc aller avec 4), et par conséquent mettre en œuvre un grand nombre à plusieurs relations beween vos entités de personnalisation et vos entités clientes. Initialement, les entites de personnalisation ne doivent pas être plus que des valeurs pour effectuer des instructions de commutation dans votre code d'application où la personnalisation doit se produire.