Pourquoi les concepteurs de base de données ne font-ils pas que les colonnes IDENTITY partent de la valeur min au lieu de 1?

Question

Comme nous le savons, Dans Sql Server, L' IDENTITY (n,m) signifie que les valeurs vont commencer à partir de n, et la valeur de l'incrément est - m, mais j'ai remarqué que tous les concepteurs de bases de données font les colonnes d'Identité en tant que IDENTITY(1,1) , sans profiter de toutes les valeurs de type de données int qui sont d' (-2,147,483,648) to (2,147,483,647),

Je prévois de faire de toutes les colonnes d'Identité en tant que IDENTITY (-2,147,483,648, 1), (les colonnes d'identité sont cachés à l'utilisateur de l'application).

Est-ce une bonne idée ?

Answer 1

Si vous trouvez que 2billion valeurs n'est pas assez, vous allez trouver que 4billion n'est pas suffisant (besoin de plus de deux fois autant de chose sur la durée de vie d'un projet, qu'il a d'abord été conçu pour en, est loin d'être rare*), si vous avez besoin de prendre une approche différente en totalité (peut-être longue valeurs, peut-être quelque chose de totalement différent).

Sinon, vous êtes juste être étrange et illisible pour aucun gain.

Aussi, qui ne dispose pas d'une base de données où l'on sait que par exemple l'article 312 est l'un avec de belles caractéristiques pour tester des choses particulières? Je sais que j'ai quelques arbitraire id gravé dans ma tête. Ils peuvent l'appeler "alors, bon, ils l'ont nommé deux fois", mais je vais toujours de savoir de New York en tant que "ville 657, couvre la plupart de nos cas de test". C'est seulement un aperçu, mais -2147482991 ne serait pas aussi pratique.

*Pour ajouter un peu de ça. Avec des choses que vous pourriez dire "ah d'environ 100" et trouve que c'est réellement 110, d'accord. Avec d'autres, vous trouverez en fait, c'est en fait de 100 000 vous étiez à l'extérieur par des ordres de grandeur. Plus le nombre est élevé, le plus souvent, l'erreur est de ce genre en raison du genre de problèmes que l'extrémité avec des estimations dans la des milliards d'être différents de ceux qui se retrouvent avec des réponses dans les dizaines. Si vous estimez 200 est votre max dans un cas donné, vous devriez probablement laisser de la place pour peut-être quelques centaines de plus. Si vous estimez 2billion dans un cas donné, vous devriez probablement laisser de la place pour quelques quadrillion plus. Cela dit, la seule fois où j'ai vu quelqu'un de réellement commencer un id au moins 2billion ils ont fini par avoir environ 3 000 lignes.

Answer 2

Sur le côté de SQL Server négatifs ID-s sont ok, traité comme un nombre positif, alors vous pourriez le faire.

Les autres sont à droite, vous devriez penser à différentes suggestion, mais les principaux problèmes sont les applications connectées à votre base de données.

Disons que prendre MS de l'Environnement. Voici un exemple: .NET DataSet est à l'aide de négatif ID-s sur autoincremented id-s pour suivre les changements dans le code. Donc peut vous aurez de la difficulté, parce que:

Le négatif touches sont utilisées pour des instances temporaires pour les lignes.

Voici la référence : MSDN

Donc definietly ce n'est pas une bonne idée de concevoir une base de données de ce genre pour MSSQL dans un MS de l'Environnement.

Answer 3

Si vous avez une classe qui représente votre table dans votre code (ce qui risque fort de se produire), chaque fois que vous créerez un nouvel objet, l'ID 0 lui sera attribué par défaut. Cela pourrait entraîner des erreurs et écraser les données de la base de données si l'ID 0 est déjà attribué. Cela permet également de déterminer facilement si un objet est nouveau ou s'il provient de la base de données en effectuant simplement if (myObject.ID != 0)

Answer 4

L'un des "gentils" effets secondaires de travailler avec des entiers proche de zéro, c'est qu'ils sont facile sur l'oeil et facile pour les développeurs, testeurs, etc à retenir, surtout avec le débogage et les tests unitaires dans l'esprit.

Aussi, les clés de substitution ont une fâcheuse tendance à s'infiltrer dans la terminologie des affaires, par exemple, les utilisateurs peuvent être en mesure de voir le PK assis dans l'URL de la chaîne de recherche en haut du navigateur le plus de chiffres dans le nombre, le plus ils sont susceptibles de paraphraser quelque chose dans un helpdesk de la requête.

Donc, c'est une des raisons pourquoi je suis très heureux de la semence de mes identités à 1 et pas à -2147483231, et au lieu de cela, ainsi que, comme @Jon suggère, se déplacent jusqu'à un BIGINT chaque fois que je peut jamais besoin de plus de 2 milliards de lignes dans ma table.

Answer 5

Lorsque vous passerez des nombres négatifs aux identifiants positifs, vous passerez à zéro. Cela signifie (en supposant que vous insérez réellement quelques milliards de lignes) que vous aurez éventuellement un identificateur égal à zéro. Ce n'est pas intrinsèquement mauvais, mais pourrait présenter un cas de figure potentiel pour les outils ORM ou tout simplement un code applicatif négligé qui a du mal à faire la différence entre un zéro et un zéro.