J'écris un nouveau programme qui nécessitera une base de données (SQL Server 2008). Tout ce que je lance maintenant pour le système est en 64 bits, ce qui m'amène à cette question. Devrais-je toutes les colonnes INT ou BIGINT pour toutes les colonnes Id dans diverses tables? Je doute que le système dépasse jamais la plage INT, mais je suppose que cela est possible dans certains des plus grands tableaux financiers. Il semble que INT soit la norme cependant ...
Réponses
Trop de publicités?
OK, faisons un petit calcul rapide récapitulatif:
INT de 32 bits et vous donne essentiellement 4 milliards de dollars des valeurs - si vous ne pouvez compter que les valeurs supérieures à zéro, c'est toujours 2 milliards de dollars. Avez-vous ce beaucoup d'employés? Les clients? Les produits en stock? Les commandes de la durée de vie de votre entreprise? VRAIMENT?
BIGINT va de façon bien au-delà. Avez-vous VRAIMENT besoin?? VRAIMENT?? Si vous êtes un astronome, ou en physique des particules, - peut-être. Une moyenne de la Ligne de l'utilisateur d'Affaires? Je doute fort qu'il
Imaginez que vous avez un tableau à - dire 10 millions de lignes (commandes de votre entreprise). Disons que vous avez une table Commandes, et que le n ° de commande qui vous a fait un BIGINT est référencé par 5 autres tables, et utilisé dans les 5 non-cluster indices sur vos Commandes de la table - mais pas trop, je pense, non?
10 millions de lignes, de 5 tableaux de plus de 5 non-cluster indices, c'est 100 millions de cas où vous êtes à l'aide de 8 octets au lieu de 4 octets - 400 millions d'octets = 400 MO. Un total de déchets... vous aurez besoin de plus de données et d'index des pages de votre Serveur SQL server devra lire plus de pages à partir du disque et de mettre en cache plus de pages.... ce n'est pas bénéfique pour votre performance pure et simple.
PLUS: Ce que la plupart du programmeur de ne pas y penser: oui, l'espace disque de saleté pas cher. Mais que de gaspiller l'espace est également pertinente dans votre Serveur SQL de la mémoire RAM et de votre base de données en cache et que l'espace n'est pas très bon marché!
Donc, pour faire un très long post court: utiliser le plus petit type de INT qui correspond véritablement à vos besoins; si vous avez de 10 à 20 valeurs distinctes pour gérer utilisation TINYINT. Si vous avez besoin d'un tableau de commande, je crois INT devrait être BEAUCOUP ASSEZ - BIGINT est seulement un gaspillage de l'espace.
Plus: si une de vos tables vraiment jamais obtenir de fermer à atteindre plus de 2 ou de 4 milliards de lignes, vous aurez encore beaucoup de temps pour mettre à jour votre table d'un BIGINT ID, si c'est vraiment nécessaire.......
Aaronaught
Points
73049
Vous devez utiliser le plus petit type de données qui fait sens pour la table en question. Que comprend l'utilisation d' smallint ou même tinyint si il y a assez peu de lignes.
Vous économiserez de l'espace à la fois les données et les index et obtenir un meilleur rendement de l'indice. À l'aide d'un bigint lorsque tous vous avez besoin est un smallint est similaire à l'utilisation d'un varchar(4000) lorsque tous vous avez besoin est un varchar(50).
Même si la machine est natif word taille est de 64 bits, ce qui signifie seulement que 64-bit CPU opérations ne sera pas plus lent que 32-bit opérations. La plupart du temps, ils ne sont pas également être plus rapide, ils vont être les mêmes. Mais la plupart des bases de données ne sont pas va être CPU, de toute façon, ils vont être dépendant des e/S et, dans une moindre mesure, liés à la mémoire, donc de 50% -90% de plus petite taille des données est une Très Bonne Chose quand vous avez besoin d'effectuer une analyse d'index de plus de 200 millions de lignes.
Rick B.
Points
71
Voici un article avec quelques vraies réponses sur la performance... je préfère répondre à des questions avec des chiffres si possible... Si vous cliquez sur le lien suivant au moins jusqu'à un million d'enregistrements, vous trouverez une différence négligeable dans l'utilisation du disque....
(Le présent site nécessite une inscription) http://www.sqlservercentral.com/articles/Performance+Tuning/2753/
Personnellement, je ne pense qu'à l'aide de la taille de l'ID est important,mais aussi considérer le fait que vous pouvez avoir une table qui a une tonne d'activités au fil du temps. Ce n'est pas que votre stockage d'une quantité massive de données, mais que la clé de la valeur a augmenté en raison de la nature de l'être auto-incrémenté (suppressions et insertions survenant au fil du temps).
Considérons un référentiel de fichiers sur un site communautaire, ou l'id de l'utilisateur des commentaires sur un site communautaire multi-locataire de l'application.
Je comprends que la plupart des développeurs sont des systèmes de construction qui ne sera jamais à toucher des millions de documents, mais il est important de noter qu'il y a des raisons pour qu'un bigint est nécessaire, et je ne suis toujours pas convaincu que lors de la conception d'un schéma que vous ne connaissez pas le potentiel de croissance pour que vous ne devriez pas essayer d'anticiper l'avenir et d'envisager l'utilisation d'un bigint si vous estimez que le potentiel est là pour dépasser la valeur max de int en tant que la valeur de l'id de pousse.
user2438530
Points
21
Les autres ont déjà donné des réponses convaincantes pour 32-bit Id.
Pour certaines applications 64 bits Id de faire plus de sens.
Si vous voulez garantir que les Id sont uniques au sein d'un cluster de bases de données - 63-bits pour les Id peut être très pratique. Avec 32 bits, il est très difficile de distribuer de la génération de l'Id sur les serveurs dans un cluster, ou dans les centres de données. Tandis qu'avec le 64 bits, vous avez assez de place pour jouer avec que vous pouvez facilement générer des Id sur les serveurs sans verrouillage et de toujours garantir l'unicité.
Voir, par exemple, Twitter Flocon de neige, et Instagram de l'Ingénierie du blog sur "Sharding & Id à Instagram". Les deux fournissent de bonnes raisons de 63 ou 64 bits font plus de sens pour leur Id de compteurs 32 bits.
gbn
Points
197263
L'alignement de 32 bits à architecture x86 ou 64 bits avec architecture 64 bits est appelée structure de données d'alignement
Cela n'a pas de sens pour les données dans une base de données parce que ici c'est des choses de l'espace disque, cache de données et de la table/index architecture qui affectent les performances (comme mentionné dans d'autres réponses).
Rappelez-vous, ce n'est pas le CPU, accès aux données en tant que telle. C'est le moteur de base de code (qui peut être aligné, mais qui s'en soucie?) qui s'exécute sur le PROCESSEUR et manipule vos données. Quand/si vos données passe par le CPU, il ne sera certainement pas dans les mêmes structures sur disque.
