Nous travaillons sur une application web, pas encore accessible aux utilisateurs. Mon patron a remarqué que les enregistrements nouvellement créés obtiennent un ID de plus de 10 000, même si nous n'avons que 100 enregistrements dans le tableau. Elle a supposé que l'interface Web, pour une raison quelconque, crée plus de 100 fois plus d'enregistrements temporaires que les enregistrements réels (et les supprime) et que cela peut nous conduire à manquer de portée dans les quelques mois suivant leur publication.
Je ne pense pas qu'elle ait raison sur la cause de l'inflation d'identité (la collègue qui peut répondre à cette question est en vacances, donc nous ne savons pas avec certitude), mais supposons qu'elle l'est. Elle a dit qu'elle détesterait utiliser une colonne bigint et qu'elle aimerait que nous arrêtions l'auto-incrémentation de la colonne ID et écrivions du code côté serveur qui choisit le premier entier "inutilisé" et l'utilise comme ID.
Je suis un étudiant diplômé en informatique avec peu d'expérience pratique, remplissant un rôle de développeur junior. Elle possède des années d'expérience dans la gestion de toutes les bases de données de notre organisation et dans la conception de la plupart d'entre elles. Je pense qu'elle est incorrecte dans ce cas, qu'un ID bigint n'a rien à craindre et que l'imitation de la fonctionnalité SGBD sent un antipattern. Mais je n'ai pas encore confiance en mon jugement.
Quels sont les arguments pour et contre chaque position? Quelles mauvaises choses peuvent se produire si nous utilisons un bigint, et quels sont les dangers de réinventer la fonctionnalité d'auto-incrémentation de la roue ? Existe-t-il une troisième solution meilleure que l'une ou l'autre? Quelles pourraient être ses raisons pour vouloir éviter une inflation des valeurs faciales d'identité? Je suis également intéressé à entendre parler de raisons pragmatiques - peut-être que les identifiants bigint fonctionnent en théorie, mais causent des maux de tête dans la pratique?
L'application ne devrait pas gérer de très grandes quantités de données. Je doute qu'il atteigne 10 000 records réels au cours des prochaines années.
Si cela fait une différence, nous utilisons Microsoft SQL Server. L'application est écrite en C # et utilise Linq to SQL.
Mise à jour
Merci, j'ai trouvé les réponses et commentaires existants intéressants. Mais je crains que vous n'ayez mal compris ma question, ils contiennent donc ce que je voulais savoir.
Je ne suis pas vraiment préoccupé par la vraie raison des ID élevés. Si nous ne pouvons pas le trouver par nous-mêmes, je pourrais poser une autre question. Ce qui m'intéresse, c'est de comprendre le processus de décision dans ce cas. Pour cela, supposez que l'application écrira 1000 enregistrements par jour, puis en supprimera 9999 . Je suis presque sûr que ce n'est pas le cas, mais c'est ce que mon patron pensait quand elle a fait sa demande. Donc, dans ces circonstances hypothétiques, quels seraient les avantages et les inconvénients de l'utilisation de bigint ou de l'écriture de notre propre code qui attribuera les identifiants (de manière à réutiliser les identifiants des enregistrements déjà supprimés, pour s'assurer qu'il n'y a pas de lacunes)?
Quant à la raison réelle, je soupçonne fortement que c'est parce que nous avons écrit du code pour importer des données d'une autre base de données, comme preuve de concept qu'une migration ultérieure peut être effectuée dans une certaine mesure. Je pense que mon collègue a créé plusieurs milliers d'enregistrements lors de l'importation et les a ensuite supprimés. Je dois confirmer si tel était bien le cas, mais si c'est le cas, il n'y a même pas besoin d'agir.