Pourquoi utiliser & # 8220; Y & # 8221; / & # 8220; N & 8282; au lieu d'un champ de bits dans Microsoft SQL Server?

Question

Je travaille sur une application développée par une autre foule et je suis dérouté par l’utilisation d’un champ char au lieu de bit pour toutes les colonnes booléennes de la base de données. Il utilise " Y " pour vrai et "N" pour faux (ceux-ci doivent être majuscules). Le nom du type lui-même est alors aliasé avec un nom obscur tel que ybln .

C’est très ennuyant de travailler pour de nombreuses raisons, dont la moindre, c’est que le résultat est carrément déplaisant sur le plan esthétique.

Mais peut-être que c'est moi qui suis stupide - pourquoi quelqu'un ferait-il cela? Est-ce un problème de compatibilité de base de données ou un motif de conception dont je ne suis pas au courant?

Quelqu'un peut-il m'éclairer?

Answer 1

J'ai souvent vu cette pratique dans les schémas de base de données plus anciens. L’un des avantages que j’ai vu est que l’utilisation de champs CHAR (1) prend en charge plus que les options Y / N, comme "Oui", "Non", "Peut-être".

D'autres affiches ont mentionné qu'Oracle pourrait avoir été utilisé. Le schéma auquel j'ai fait référence était en fait déployé sur Oracle et SQL Server. Elle limitait l’utilisation des types de données à un sous-ensemble commun disponible sur les deux plates-formes.

Ils ont bien divergé à certains endroits entre Oracle et SQL Server, mais ils utilisaient généralement un schéma commun entre les bases de données pour minimiser le travail de développement nécessaire à la prise en charge des deux bases de données.

Answer 2

Bienvenue sur Brownfield. Vous avez hérité d'une application conçue par des vieux élèves. Ce n'est pas un modèle de conception (du moins pas un modèle de conception avec quelque chose de bien), c'est un vestige de programmeurs qui font leurs armes dans des bases de données contenant des types de données limités. Sans refactoriser la base de données et beaucoup de code, serrez les dents et frayez-vous un chemin à travers (et surveillez votre cas)!

Answer 3

Les autres plates-formes (par exemple, Oracle) n'ont pas un type de bit SQL. Dans ce cas, vous avez le choix entre NUMBER (1) et un champ à un caractère. Ils ont peut-être commencé sur une autre plateforme ou voulaient une compatibilité entre plates-formes.

Answer 4

Je n'aime pas trop le champ Y / N char (1) en remplacement d'une colonne de bits, mais il y a un inconvénient majeur dans un champ de bits dans une table: vous ne pouvez pas créer un index pour une colonne de bits ou l'inclure dans un index composé (du moins pas dans SQL Server 2000).

Bien sûr, vous pouvez discuter de la nécessité éventuelle d’un tel index. Voir cette demande sur un SQL Forum serveur .

Answer 5

Les raisons sont les suivantes (au fait, ce ne sont pas de bonnes raisons):

1) Y / N peut rapidement devenir "X". (pour inconnu), " L " (pour probable), etc. - Ce que je veux dire par là est que j'ai personnellement travaillé avec des programmeurs qui étaient tellement habitués à ne pas bien collecter les exigences qu'ils venaient de commencer avec Y / N comme une sorte de "drapeau" avec la superstition qu'il pourrait besoin de développer (auquel ils doivent utiliser un int comme identifiant de statut).

2) " Performance " - mais comme mentionné ci-dessus, les index SQL sont exclus s'ils ne sont pas assez "sélectifs" ... un champ qui n'a que 2 valeurs possibles n'utilisera jamais cet index.

3) Lazyness. - Parfois, les développeurs souhaitent imprimer directement sur un écran avec la lettre "Y". ou " N " pour la lisibilité humaine, et ils ne veulent pas le convertir eux-mêmes:)

Il y a trois mauvaises raisons que j'ai entendues / vues auparavant.

Answer 6

Je ne vois pas d'inconvénient à ne pas pouvoir indexer un "BIT". colonne, car il serait peu probable qu’il y ait suffisamment de valeurs différentes pour faciliter l’exécution d’une requête.

J'imagine également que, dans la plupart des cas, la différence de stockage entre BIT et CHAR (1) est négligeable (s'agit-il d'un CHAR NCHAR? stocke-t-il un caractère unicode 16 bits, 24 bits ou 32 bits? Est-ce que nous nous en soucions vraiment?)

Answer 7

C’est terriblement courant dans les fichiers mainframe, COBOL, etc.

Si vous n'avez qu'une seule colonne de ce type dans un tableau, ce n'est pas si terrible en pratique (pas de gaspillage de bits); Après tout, SQL Server ne vous laissera pas dire le code naturel WHERE BooleanColumn , vous devez dire WHERE BitColumn = 1 et IF @BitFlag = 1 à la place. bien plus naturel IF @BooleanFlag . Lorsque vous avez plusieurs colonnes de bits, SQL Server les compresse. Le cas de Y / N ne devrait être un problème que si un classement sensible à la casse est utilisé, et pour arrêter les données non valides, il existe toujours l'option d'une contrainte.

Cela dit, mes préférences personnelles concernent les bits et n'autorisent que les NULL après mûre réflexion.

Apparemment, les colonnes de bits ne sont pas des bonne idée dans MySQL .

Answer 8

Ils ont peut-être commencé le développement avec Microsoft SQl 6.5

À l'époque, l'ajout d'un champ de bits à une table existante avec des données en place était une douleur royale à l'arrière. Les champs de bits ne peuvent pas être nuls. La seule façon d'en ajouter un à une table existante est de créer une table temporaire avec tous les champs existants de la table cible ainsi que le champ de bits, puis de copier les données dessus, en remplissant le champ de bits. avec une valeur par défaut. Ensuite, vous deviez supprimer la table d'origine et renommer la table temporaire en son nom d'origine. Ajoutez quelques relations clés à l’avance et vous aurez un long script à écrire.

Cela dit, il y avait toujours des outils tiers pour vous aider dans le processus. Si le développeur précédent a choisi d’utiliser des champs de caractères au lieu de champs de bits, la raison en est probablement la paresse.

Answer 9

Ils étaient probablement habitués à utiliser Oracle et ne lisaient pas correctement les types de données disponibles pour SQL Server. Je suis moi-même dans cette situation (et le champ Y / N me rend fou).

Answer 10

J'ai vu pire ...

Un mappeur O / R avec lequel j'ai eu l'occasion de travailler a utilisé les termes "vrai" et "faux", car ils pouvaient être proprement moulés dans des booléens Java.

En outre, sur une base de données de rapports telle qu'un entrepôt de données, la base de données constitue l'interface utilisateur (nonobstant les outils de génération de rapports basés sur les métadonnées). Vous voudrez peut-être faire ce genre de chose pour aider les personnes à rédiger des rapports. En outre, un index avec deux valeurs sera toujours utilisé par les opérations d'intersection d'index sur un schéma en étoile.

Answer 11

Parfois, ces bizarreries sont davantage associées à l'application qu'à la base de données. Par exemple, gérer des booléens entre PHP et MySQL est un peu hasardeux et crée un code non intuitif. L’utilisation des champs CHAR (1) et des symboles "Y" et "N" permet d’obtenir un code beaucoup plus facile à gérer.

Answer 12

Je n'ai pas de sentiments forts de toute façon. Je ne vois aucun avantage à le faire d’une manière ou d’une autre. Je sais que, philosophiquement, les champs de bits sont meilleurs pour le stockage. En réalité, très peu de bases de données contiennent un grand nombre de champs logiques dans un seul enregistrement. Si j'en avais beaucoup, je voudrais certainement des champs de bits. Si vous n'en avez que quelques-uns, je ne pense pas que cela compte. Je travaille actuellement avec des bases de données de serveurs Oracle et SQL et j’ai commencé avec la base de données IDMS de Cullinet (1980), dans laquelle nous stockions toutes sortes de données dans des enregistrements et nous inquiétions des bits et des octets. Bien que je s’inquiète toujours de la taille des données, j’ai depuis longtemps arrêté de me préoccuper de quelques bits.