Question

Je travaille sous régime refactorisation de base de données (SQL Server 2008) et de recueillir des arguments pour modifier les colonnes de NCHAR(1) (qui maintiennent les valeurs de Y|N) à BIT. Tout le monde comprend cela est nécessaire et ne sais pas pourquoi at-il lieu, mais ce changement affecte la base de données de production si des arguments de poids sont nécessaires. Tableau conserve catalogue d'adresses (jusqu'à 1 m des dossiers).

Le premier argument que je trouve - chacun des champs nchar prennent 2 octets , chaque 8 champs de bits - 1 octet (8 suivant - 1 supplémentaire octet).

Et ensuite? Peut-être quelques problèmes de performance des indices?

Était-ce utile?

La solution

Un champ de bits permet à votre logique en appliquant automatiquement ce qui est actuellement une règle implicite d'affaires (à savoir, cette colonne ne peut contenir que « Y » ou « N »). Si vous appliquer cette règle programme, vous pouvez économiser en éliminant ces frais généraux. L'indexation d'une colonne peu sur son propre a peu de valeur en raison de la faible cardinalité, mais il pourrait être utile dans le cadre d'un indice composite.

Voir aussi:

Autres conseils

Je hésite à fournir des arguments pour un tel changement, sauf si vous avez eu une bonne raison de faire ce changement. à-dire que vous devez équilibrer le coût d'un changement à ce que vous personnellement fait / préférer, contre le coût de la mise en œuvre effectivement et les avantages.

Avez-vous vérifié si l'utilisation de nchar (1) est mal performance, ou êtes-vous tomber dans le piège de-optimisation prématurée? Vous parlez seulement environ 1 million d'enregistrements ici.

Pour vous encourons, le stockage mineur / IO vous coûte que considérer le total des heures de l'homme au changement, nouveau test et de mise à niveau du système * taux horaire vs coût de simplement acheter un disque plus rapide. Je soupçonne que le disque sera beaucoup moins cher -. Ainsi que de bénéficier tous les aspects du système

Une raison commune de trouver NCHAR (1) au lieu de bits est que Oracle ne prend pas en charge un type de bits. Si vous aviez un Oracle ou développeur formé Oracle, ou une base de données utilisée pour exécuter sur Oracle, tu vas voir ce lot. Dans Sql Server, il n'y a vraiment pas besoin de cela.

Cependant, j'ai trouvé que la plupart des endroits où j'ai un champ de bits (ou NCHAR (1) dans Oracle) ce que je vraiment besoin est un datetime qui indique pas autant la valeur de la drapeau, mais exactement quand il est devenu vrai. Ce n'est pas toujours le cas, mais quand je repense ancien code que j'ai écrit je suppose que 4 fois sur 5 j'ai utilisé un champ de bits je l'ai utilisé un datetime.

Créer le champ de bits, ajouter une colonne calculée qui émule le nchar (1) pour l'instant.

À ne pas utiliser nchar:

  • Y vs vs y certains unicode Y
  • Frais généraux de vérification Y ou N
  • Non nativement "true" o "false" (par exemple, ne sera pas la carte directement .net booléen)
  • Y et N sont l'anglais. Ja / Nein, Oui / Non etc

Vous ne devriez pas indexer cela de toute façon il revient au stockage et à l'utilisation efficace. bit est

  • petit
  • type de données de sécurité (par exemple, pas CHÈQUE nécessaire)
  • cartes au client signifie directement
  • indépendant de la région

Dire que, nous utilisons un smalldatetime « WhenInactive » champ comme substitut pour le champ « IsActive ». NULL = active.

Si vous utilisez LINQ2SQL ou Entity Framework une colonne de BIT se traduira par une bool, mais NCHAR(1) se traduira par une string.

Le champ largement utilisé dans les requêtes Where fld = 'Y'?

Si donc j'envisager de faire un test pour voir si oui ou non la modification à la performance des impacts de bits.

Modification maintenant juste parce qu'il devrait être un champ de bits puisque vous stockez des valeurs booléennes sur une table de 1 m + enregistrements ne semble pas être une bonne idée pour moi non plus et je partirais avec @ réponse d'Andrew.

Utilisez Bit:

  • Représentation logique / expressivité d'intention - car les états booléens ne sont pas toujours exprimable toujours comme Yes or No, ce qui voudrait dire que vous soit besoin d'être incompatibles en bits de modélisation, ou non-intuitive, par exemple True/False (T/F), On/Off (?O/F), Open/Closed(O/C) etc.

  • L'intégrité référentielle - bit non annulable peut être limité à seulement 0 or 1. À moins que vous ajoutez des contraintes, votre *char(1) pourrait être Y, N, X ou ☺.

  • bits peuvent être emballés , cela pourrait avoir plus petit stockage.

  • Re: Rendement: Indexation de bit (ou peu à l'état CHAR) colonnes est généralement une perte, à moins d'une sélectivité élevée de 0 ou 1 dans les données. Dans ce cas, un Filtré sur la valeur sélective serait une bonne idée.

( supprimé réponse )

J'ai eu quelques occasions où nous voulions un champ de bits, mais ne pouvait pas savoir à coup sûr qu'il n'y aurait jamais la nécessité d'une troisième valeur ou quatrième dans ce domaine. Nous avons structuré donc comme un champ de chaîne contenant Y ou N. Bien sûr, nous ne l'avons fait dans des situations très particulières.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top