我们正在开发一个 Web 应用程序，用户尚无法访问。我的老板注意到新创建的记录的 ID 超过 10 000，即使表中只有不到 100 条记录。她假设 Web 界面出于某种原因创建了比实际记录多 100 倍的临时记录（并删除了它们），这可能导致我们在发布后的几个月内超出范围。
我不认为她关于 ID 膨胀的原因是正确的（可以回答这个问题的同事正在休假，所以我们不确定），但让我们假设她是。她说她讨厌使用 bigint 列，她希望我们停止自动递增 ID 列并编写服务器端代码，选择第一个“未使用”的整数并将其用作 ID。
我是一名计算机科学研究生，几乎没有实践经验，担任初级开发人员的角色。她在管理我们组织的所有数据库和设计其中大部分数据库方面拥有多年经验。我认为在这种情况下她是不正确的，bigint ID 没有什么可害怕的，并且模仿 DBMS 功能的反模式气味。但我还不相信我的判断。
支持和反对每个立场的论据是什么？如果我们使用 bigint 会发生什么坏事，重新发明轮子自动递增功能有什么危险？有没有比任何一种都更好的第三种解决方案？她想要避免身份证面值膨胀的原因是什么？我也有兴趣了解实际原因 - 也许 bigint ID 理论上可行，但在实践中会引起头痛？
该应用程序预计不会处理大量数据。我怀疑它会在未来几年内达到 10 000 条实际记录。
如果它有任何区别，我们正在使用 Microsoft SQL 服务器。该应用程序是用 C# 编写的，并使用 Linq to SQL。
更新
谢谢，我发现现有的答案和评论很有趣。但恐怕你误解了我的问题，所以它们包含了我想知道的。
我并不真正关心高 ID 的真正原因。如果我们自己找不到它，我可以问一个不同的问题。我感兴趣的是了解这种情况下的决策过程。为此，请假设应用程序将每天写入 1000 条记录，然后删除其中的 9999 条。我几乎可以肯定事实并非如此，但这就是我的老板提出要求时所相信的。那么，在这些假设情况下，使用 bigint 或编写我们自己的代码来分配 ID（以重用已删除记录的 ID 的方式，以确保没有间隙）的优缺点是什么？
至于实际原因，我强烈怀疑这是因为我们曾经写过代码从另一个数据库中导入数据，作为概念证明，以后可以在一定程度上进行迁移。我认为我的同事在导入过程中实际上创建了数千条记录，后来又删除了它们。我必须确认是否确实如此，但如果是，则甚至不需要采取行动。