Les champs booléens d'une table peuvent être nommés à l'aide de la valeur positive de la valeur négative ...
Par exemple, appelant un champ: P>
"ACTIVE" , 1=on / 0=off or "INACTIVE" , 0=on / 1=off
7 Réponses :
Je préfère toujours des noms positifs, pour éviter les doubles négatifs dans le code. "N'est pas inactif" est souvent une raison pour une double prise lors de la lecture. "Est inactif" peut toujours être écrit comme "si (! Actif)" tout en profitant de la sémantique de langue intégrée.
Certains mots ont eux-mêmes des significations négatives et ne sont pas faciles à trouver leurs contre-pièces positives - quelle est une meilleure alternative pour "isunblocked"? "est autorisée"? Je me sens plus à l'aise placer "bloc" / "débloquer" plutôt que "bloquer / permettre" dans les éléments de menu GUI. Pour ce cas, j'essaie d'utiliser "ISBLOCKED" dans mon code (qui est un nom négatif) car "isunblocké" est confus et "isowlocked" n'est pas cohérent avec le menu GUI.
Mes préférences personnelles:
Dans votre cas d'utilisation spécifique, le champ doit être nommé ispublic ou isprivate - selon le nom de la réponse réelle lorsque l'utilisateur tire la case.
... et qu'en est-il des négatifs intégrés de la conception comme "Lockout Line"? L'appareil est inactif si la ligne de verrouillage est élevée. Islockedout signifie à peu près ISDEviceInActive. Mais lorsque je teste la ligne de verrouillage, je suis intéressé par IslockOUTActive ... ou, estworkingCorrectement ou isinfaultmode?
SF, je ne suis pas sûr que je suive votre logique ici, mais je pense que vous avez peut-être dépassé le but d'une valeur booléenne et peut avoir besoin d'un champ de statut, avec une liste de recherches de valeurs d'état possibles. La réponse des poneys OMG est la bonne dans ce cas.
Utilisez toujours des noms positifs.
Si vous utilisez des noms négatifs, vous entrez très rapidement dans la double négation. Pas que la double négation est une chirurgie de fusée, mais c'est un cycle cérébral et ceux-ci sont précieux :)
Utilisez toujours positif.
C'est plus simple.
Prenez l'utilisation de la négation à l'extrême logique: si inactive est meilleur que actif, alors pourquoi pas ininactif, ou ininininactif?
parce que ce serait moins simple.
La bonne façon de gérer ces situations est de créer une table pour accueillir les valeurs associées à la colonne et de créer une relation de clé étrangère entre les deux tables. IE:
Si possible, Vous voulez faire cela parce que:
widgets Table:
widget_id
widget_status (fk)
widget_status_codes Table:
widget_status_code (pk)
Description
widget_status_code serait une clé naturelle (c'est-à-dire: acte "actif", INA pour "inactif"). Cela rendrait des documents plus lisibles par l'homme, mais ne sont pas toujours possibles, vous devez donc utiliser une clé artificielle / substitution (comme un numéro automatique / séquence / etc.).
C'est beaucoup moins efficace qu'un simple champ de bits. Quelle est la justification de faire cela par rapport à un champ de bits simple pour une simple réponse booléenne?
(a) La lisibilité humaine des tables nues n'est pas, IMHO, un objectif de bonne conception de base de données. Sinon, nous n'utiliserions jamais les clés de substitution et nos bases de données dépenseraient toute leur vie à faire des comparaisons de chaîne.
(b) Je suis d'accord en principe avec une vérification future pour plus de valeurs, mais uniquement s'il existe un statut possible qui n'est ni des choix existants. Nommer un champ quelque chose de générique comme "Statut" quand il doit vraiment faire seulement avec le mode actif / inactif invite les abus futurs par des attributs orthogonaux de chaussures. Finalement, cela oblige la conception vers une relation m: n qui ressemble à un nuage de tags de typement. Je ne suis pas contre les clouds de tags en général, mais ils rompent la normalisation et qui a des conséquences pour la conception.
c) L'intégrité référentielle n'est pas nécessaire pour un champ booléen / bit, car la liste des valeurs est déjà limitée à 1/0.
+1, j'ai tendance à éviter les types de données de bits, sauf si vous avez une table avec de nombreux drapeaux VRAI / FAUX qui ne peuvent pas être combinés dans un indicateur d'état. Une seule colonne de bits dans une table prendra toujours un octet pour la stocker. Je vais simplement utiliser une contrainte de vérification s'il s'agit d'un statut = "A" ctive- "i" nactive, mais utilisez une table FK et une table si vous avez des valeurs plus et / ou étranges telles que "Q", etc.
(d) L'espace est bon marché, mais les comparaisons de cordes ne sont pas, et ni des jointures, en particulier lorsque le nombre de valeurs potentielles est deux.
Km, un seul champ de bits pas prend un octet dans MSSQL, à moins que ce ne soit le champ uniquement Bit dans la table. Ce n'est pas que 7 bits seraient un énorme déchet, mais simplement dire ... à l'aide de champs Varchar () avec des contraintes de contrôle ou des clés étrangères à d'autres tables pour stocker de simples valeurs booléennes.
@Richardtallent, calme-toi. J'ai dit: Une colonne de bits unique dans une table prendra toujours un octet pour le stocker qui est 100% vrai. En outre, je n'ai jamais dit qu'une colonne d'état devrait être Varchar.ca (); Un char (1) fait très bien. J'ai vu beaucoup de gens utilisent très mal la colonne de bits. Ils fabriquent plusieurs colonnes vraies / fausses pour suivre un statut, comme pour une facture: ISVALID, ISPAID, ISPOSTED, ISPOMPLETE; Lorsqu'une colonne d'état unique avec valeurs "V", "P", "O", "C" et une table de la descriptive Fonctionne beaucoup mieux pour moi rend tout le code simple unique pour suivre l'état, pas plusieurs.
@Km: Vous avez manqué votre point sur Bit - Désolé. Mais en utilisant un char (1) comme vous l'avez décrit uniquement fonctionne si les valeurs sont dépendantes . Plusieurs fois, les concepteurs de base de données font l'erreur de roulement de champs de statut indépendants en concevant un flux de travail idéal (E.g, en supposant que cela implique ISPAID, etc.). Lorsqu'un enregistrement dans le monde réel saute autour, saute des étapes, etc., vous perdez des informations importantes. Mais mon problème concerne spécifiquement la mise en œuvre de champs véritablement booléens de cette façon - une conception flexible est bonne, mais IMHO ceci rompt Yagni et ne doit pas être une règle de base.
Je ne voudrais pas être en désaccord avec certaines des autres réponses, mais évite définitivement la réponse incorrecte qui ne doit pas mettre à doubles négatifs toujours
Essayez d'éviter les champs booléens dans des bases de données allommander.
Un, le RM a un bien meilleur moyen de représenter des informations valorisées de vérité que via des champs booléens: via la présence d'un tuple dans une table.
Deux champs booléens sont de très mauvais discriminateurs lors de la question. La folie est pratiquement complète de les indexer, alors lors de la question, la présence de champs booléens ne donne aucun avantage du tout.
Les valeurs booléennes peuvent être de mauvais discriminateurs, mais cela dépend entièrement sur la distribution de valeurs 0 et 1. Comme n'importe quel index, l'indexation d'un champ de bit ajoute un élément d'indirection de la recherche de table s'il ne s'agit pas de la colonne de première commande d'un index en cluster (que je ne recommande pas), mais indexation fait éviter une table Numériser, donc là est une prestation de performance. En attendant, l'utilisation d'un FK sur une autre table avec une valeur unique contient exactement la limitation des performances en tant que champ de bits indexé, et pour la même raison, mais les jointures ont ajouté des frais généraux supplémentaires substantiels par rapport à une recherche d'index de bit.
Vous devez créer une autre table et mettre en œuvre une relation de clé étrangère - voir ma réponse pour plus de détails.