Question

我正在设计一个数据库，并且我有许多表可能会超出标准32位int的最大大小。然而，在这种情况发生之前可能还需要几年时间，并且无法保证它甚至可能实际发生。

然而，鉴于它有可能发生，我应该继续为主键选择bigint吗？现在这样做会有什么影响，以后再改变它？是否有可能在以后将int主键转换为bigint，如果是这样，它有多难，是否可行？

Answer 1

Going BIG将花费你的存储和性能 - 特别是如果它意味着你的外键引用也必须是BIGINT。

展望未来的“岁月”并不一定是谨慎的事情。预计大多数（并非所有）IT项目将在3年内收回成本。多年来，您很可能不得不应对大量的更改和升级，如果您的数据库在这段时间内增长如此之多，那么在您需要时将INT更改为BIGINT的工作量不应太大。到那时，也许您的业务和数据库世界将会继续前进，这将不再是一个问题。 YAGNI规则。

Answer 2

本身没有理由避免它。它确实需要更多的存储空间。如果这是主键列，则除非先删除主键，否则无法更改数据类型。假设您命名主键约束，这非常简单。您不必像在lad2025的评论中那样创建一个新列并完成所有hocus pocus废话。

create table IntTest
(
    MyID int identity 
    , SomveValue uniqueidentifier
    , constraint IntTest_PK primary key clustered (MyID)
)

insert IntTest
select NEWID()
from sys.all_columns

alter table IntTest drop constraint IntTest_PK

alter table IntTest alter column MyID BigInt

alter table IntTest add constraint IntTest_PK primary key clustered (MyID)

有没有理由避免使用bigint作为代理主键？

2 个答案: