Ce type de données que je devrais utiliser de préférence pour le stockage de pavillon champs dans sql server?

Ce type de données que je devrais utiliser de préférence pour le stockage de pavillon champs dans sql server, peu(si j'ai seulement 0,1 et null), tinyint, smallint ou int pour les drapeaux qui ne peuvent pas être logés dans peu? Prend-il en effet de ma performance d'une requête?

  • Dépend du nombre de valeurs différentes, le drapeau peut contenir. Moins de 255 Tinyint de le faire. Je ne pense pas qu'il n'y aura aucune différence notable dans les performances.
  • Fred est correct. C'est le meilleur choix, et il laisse de la place pour grandir. Certains ont suggéré un NULLable peu, mais IMO, c'est ambigu. Un bit est à 1 ou 0. NULL PEU de moyens n'est pas défini, et est plus compliqué à contourner. Oui, il peut être utilisé. Oui, il existe des situations particulières qui en ont besoin. Mais tout de drapeaux doivent utiliser TINYINT.
  • Si j'ai à choisir entre tinyint, short ou Int pour les drapeaux dont un pour aller avec le point de vue des performances? Laissez Peu à part comme il peut stocker des drapeaux à 0 et 1 seulement.
  • désolé de prendre tant de temps pour répondre. "Ça dépend" sur la façon dont vous utilisez le drapeau. Si vous êtes à les coordonner avec un enum dans votre code, puis ce qui compte c'est le nombre de choix que vous embrasser, et si oui ou non vous les combiner (vrai drapeaux). Choisissez la largeur minimale qui serviront de données. Cela peut rendre l'interrogation un peu klunky, si vous avez d'analyser les valeurs. Dans ce cas, vous pouvez sentir que les normaliser (à l'aide d'une table liée) sera plus utile. Certains souhaitent utiliser un masque de bits. Cela peut être difficile à coder--et valider. Le débit et le temps de traitement sont des facteurs clés.
  • Jetez un oeil à ce commentaire. dba.stackexchange.com/questions/4968/...
  • Merci pour le lien que vous avez fourni, j'ai exactement ce dont j'avais besoin

InformationsquelleAutor Niraj | 2013-11-13
  1. 4

    Utiliser Bits Type de données qui est mis à 1 si la valeur est true ou 0 ir Faux, beaucoup plus petit et plus rapide pour interroger sur la valeur des Bits de Votre colonne peut être enregistré que 1 Octet si vous avez 8 ou moins de Bits colonnes de votre tableau et je pense que si vous avez plus de 8 SQL Server utilise 2 Octets de la Colonne , Qui est beaucoup plus petit que les autres options que vous pourriez avoir, tinyint, smallint et int nécessite plus d'espace, un peu à la colonne et l'interrogation d'un plus grand type de données signifie plus de temps pour interroger les données.

    Ma Suggestion

    Ma Suggestion serait d'utiliser des Bits de la Colonne, car elle nécessite moins d'espace pour les stocker et les requêtes peuvent effectuer beaucoup plus rapidement.

    • Merci pour votre suggestion, je suis petite bien ok avec l'aide de Bits type de données pour les drapeaux, mais je veux savoir le type de données dans le cas où si les valeurs d'indicateur sont plus grands et ne peuvent pas être logés dans un peu? et je veux aussi savoir pourquoi(liées à la performance des requêtes). par exemple j'ai 10 différentes valeurs d'indicateur, alors dans ce cas le type de données que je devrais utiliser et pourquoi?
    • Le problème avec les bits est bien sûr que vous avez besoin d'un schéma de modifier à tout moment vous voulez un nouveau drapeau.
    InformationsquelleAutor M.Ali
  2. 1
    bit

    son un booléen, donc c'est seulement 1 ou 0, et ne nécessite pas un ensemble d'octets pour stocker. De Plus, vous pouvez simplement faire nullable sur la conception de la table.

    • J'ai édité ma question pour effacer votre confusion, je veux savoir la suggestion dans le cas où si le drapeau valeurs sont plus grandes que peuvent être logés dans un peu? et je veux aussi savoir pourquoi(liées à la performance des requêtes).
    • Droit, de sorte que vous ne voulez pas qu'un PEU. Utiliser un char(1) à la place??
    • Être pointilleux ici: SQL Server bit type de données n'est pas un booléen. Façon la plus simple pour illustrer cela est SELECT 'hmm' WHERE Cast(1 As bit). Vous recevrez un message d'erreur car la clause where n'est pas évalué. Si c'était un vrai booléen alors vous n'auriez pas besoin d'ajouter un opérateur = pour que cela compile.
    • sera char être plus rapide que tinyint ou court ou de type int, avec le point de vue des performances lors du stockage numérique des valeurs d'indicateur?
    InformationsquelleAutor Rich
  3. 1

    J'ai eu la réponse pour ce que je cherchais, nous devrions envisager d'utiliser le plus petit type de données suffisant pour stocker les valeurs d'indicateur requis. C'est à l'égard de la performance de base de données comme la taille de stockage n'est pas un gros problème ces jours-ci.

    jetez un oeil à cette lien pour plus d'informations.

    Que par ce lien, pensez à la façon dont les ressources autres que de l'espace disque utilisé, pensez à pool de mémoire tampon de stockage et de bande passante. À l'extrême fin, de cache du PROCESSEUR et de la mémoire de la bande passante du bus, et aussi sur la façon dont SQL Server fonctionne.

    InformationsquelleAutor Niraj