Comment traitez-vous char (1) à la place d'un champs booléen et à trois états?

Question

Un peu lié à ma question sur les entiers au lieu des nombres décimaux; mon fournisseur fournit beaucoup de champs "booléens" au format char (1) (c'est-à-dire Y/N). Certains de ces champs ne peuvent légitimement être un booléen car ils peuvent avoir plusieurs valeurs, mais la majorité peut être traitée comme un booléen. Dans ma question précédente, le conseil était de faire ce qui est "juste" au lieu de ce que le vendeur fournit; devrais-je encore appliquer cette logique et créer mon schéma de base de données en utilisant un champ de bits pour ces colonnes, ou le garder en tant que char (1) et faire la conversion dans mon code?

Toujours sur ce sujet, comment traiter les champs à trois états en ce qui concerne le code? Logiquement, le champ est un booléen (en ce sens que je ne m'intéresse qu'à la valeur Y/N et la troisième valeur est vraiment oui ou non), mais les valeurs peuvent être plus que vrai/faux (par ex. UpsShippable champ qui peut être Y, N ou G); ce champ a plusieurs états alors comment pourrais-je le mieux l'encapsuler? Quelque chose comme un enum (ou des constantes statiques, puisque Enums ne peut pas être utilisé avec le type de données char)? Dans les cas à valeurs multiples, les données ressemblent plus à un indicateur de type qu'à un indicateur. Pour résumer (je suis un peu long): 1) En traitant les valeurs char(1) dans les données, les conservez-vous en tant que caractères ou convertissez en bit (ou quel que soit le type booléen de votre base de données) et pourquoi, et 2) Comment aborderiez-vous un champ de caractères à trois états dans votre code, en supposant que vous le laisseriez comme char(1) dans le schéma de données?

EDIT: Pour clarifier, aucun de ces champs n'est utilisé pour la "vraie" logique, c'est simplement un indicateur. Par exemple, si l'article n'est pas expédiable via UPS (c'est-à-dire que la valeur est N/G), il indique que l'article ne peut pas être expédié par l'intermédiaire de l'UPS. un appel au service Web d'UPS pour calculer l'expédition. Les autres champs Y/N sont simplement là en tant que détails supplémentaires sur un élément et n'ont aucune logique, bien qu'ils doivent être modifiables (par exemple, avoir une case à cocher indiquant si elle est recyclée sur un formulaire de saisie de données); Je pourrais afficher une image ou des éléments de filtre par eux (par exemple, vous pouvez rechercher tous les produits recyclés, et je vais vérifier pour s'assurer que leur indicateur recyclé est vrai) mais rien d'autre, du moins pas pour le moment.

Answer 1

Je suggérerais dans les champs de bistate, vous faites toujours les conversions booléennes.

Le domaine des trois états est quelque chose de différent ... Il y a beaucoup de solutions, aucune n'est vraiment "juste". Vous pouvez créer des tables pour les jeux d'options, et les lier par index ... mais vous perdez en lisibilité humaine pour très peu de gain, sauf pour être "juste".

Answer 2

Je fais le plus souvent affaire avec Oracle qui n'a pas vraiment de types de bits donc ça n'a jamais vraiment été un problème. Ceci étant dit, les champs d'un code de caractère sont communs et très bien. Quoi que vous fassiez, ne leur donnez pas un nom trompeur qui suggère que c'est un type booléen s'il avait 3 états. Cela va simplement embrouiller les gens.

Nom Bad: SHIP_FLAG ('drapeau' est ambigu, mais beaucoup interprétera comme Y/N ou T/F)
Nom Bad: HAS_BOOKED (encore une fois, implique booléen)
Nom Bad: IS_SENT (idem)
Bon nom: SHIP_CODE (cela peut signifier tout ce que vous voulez dire)

De plus, les champs d'un caractère vous permettent d'étendre la signification plus tard. Les champs de bits ne le font pas (vraiment).

Answer 3

1 :) Cela dépend si le caractère (1) est seulement un champ de type Y/NT/F alors oui je le convertirais en un bit, parce que c'est un booléen, je ferais la conversion au format spécifique au fournisseur à la limite du système (Imaginez que vous ayez plusieurs fournisseurs comme FedEx et UPS, vous pourriez généraliser votre système dorsal pour gérer les deux expéditeurs, puis ajouter des composants spécifiques pour communiquer avec votre modèle et le leur). 2 :) S'il y a plusieurs états alors ce n'est plus un booléen et je le stockerais dans un format qui aurait du sens certaines options seraient de le stocker comme un champ char, ou vous pourriez créer une table de recherche afin pour UpsShippable vous pourriez avoir Oui, Non ou Ground. Eh bien, une table de recherche vous permet de stocker une information plus descriptive sur ce que G signifie. Si j'utilise un Enum dans le code dépend beaucoup de ce que le but du champ et de votre projet est. Si vous allez exécuter la logique contre le champ alors je pourrais envisager d'utiliser une énumération qui va bien avec une table de recherche, si vous simplement stocker et passer les données alors peut-être que je ne le ferais pas.

Answer 4

J'ai décidé d'aller de l'avant et d'implémenter les champs Y/N simples comme de véritables champs de bits, mais je ne suis toujours pas sûr de la façon dont je devrais aborder les champs de caractères multi-états.

Je devrai les utiliser comme drapeaux pour indiquer si d'autres actions doivent être prises; par exemple, à moins que le ShippingStatusCode soit Y, l'élément est considéré comme et non être UPS expédiable et un ensemble de logique différent s'applique que s'il était expédiable. La logique peut aller de ne pas afficher certaines options à remplacer réellement des éléments qui ont été entrés dans un formulaire avec un élément totalement différent, ou le supprimer complètement si une recherche indique qu'il n'y a pas d'éléments équivalents.

Un problème en panne .. un à emporter. Des réflexions sur les champs multi-états? Je dois les laisser comme champs de char, bien que je pense que je vais pécher par excès de prudence et utiliser un char (3) au lieu de char (1) juste au cas où les exigences changeraient à un moment donné.

Answer 5

J'ai été confronté à une situation similaire il y a un certain temps. Je construisais une application contre une base de données sur laquelle je n'avais aucun contrôle, qui utilisait les champs Y/N de char (1) pour les booléens. J'utilisais également le framework ORS SubSonic pour construire ma couche d'accès aux données. Ce que j'ai fait était de créer une autre propriété sur la classe pour une table à convertir vers/depuis le champ char (1).

public string SomeYNField { ... } // property generated by ORM tool 

    // property added manually (in a partial class, so 
    // it doesnt get blown away by the ORM tool) 
    public bool SomeYNFieldBool 
    { 

     get 
     { 
      // Anything other than a "Y" is false. 
      return SomeYNField.Equals("Y", StringComparison.InvariantCultureIgnoreCase); 
     } 
     set 
     { 
      SomeYNField = value ? "Y" : "N"; 
     } 
    } 

Vous pouvez maintenant utiliser ce champ booléen pour lier les cases à cocher et les autres contrôles qui attendent des booléens.

Answer 6

Vous pouvez créer une vue qui casse les champs booléens à trois états dans un champ de type NULLable.

Par exemple:

CASE UpsShippable WHEN 'Y' THEN 1 WHEN 'N' THEN 0 ELSE NULL END 

Si vous créez ce point de vue comme une vue indexée, il n'y aura pas de frais généraux lors de la sélection des données.