我正在清理旧数据库。我有一个表User,为User.SequenceNumber列设置了Identity 1,1,该列用作许多表中的外键作为用户ID号。另一个表UserNotes在过去几年中错误地添加了许多记录,UserNotes.UserID为零。我最初的想法是使用User.UserName为'Unknown'添加User.SequenceNumber为零,以恢复User.SequenceNumber和UserNotes.UserID之间的外键约束。我已经能够在测试区域成功完成这项操作并记录了一些记录。
我担心的是,当我添加“零”行时,它会在我的500万以上数据库中开始引起问题,该数据库每分钟有大约6次读取加上4条记录吗?我发现人们在数据库执行此操作时遇到问题,当他们不希望这种情况发生时,而不是有人想要故意这样做的地方。
答案 0 :(得分:1)
就数据库而言,在定义为IDENTITY(1,1)
的列中插入0应该没问题,因为您将插入一个超出为自动生成的值分配的范围的值(假设为int
},是[1..2,147,483,647]
),意味着您的任意值不会干扰自动值生成。
此可能会影响您的应用程序,但不太可能。例如,如果您的应用程序将0引用视为特殊值,而不是因为它为0,但由于SequenceNumber = 0
中没有User
的行,则该逻辑将在添加0时被破坏行。
或者,您可以使用NULL替换UserNotes.UserID
中的所有零。在我看来,这是指定“未知”参考的更自然的方式。另一方面,我似乎也更有可能影响应用程序,也可能更大程度地影响应用程序 - 特别是如果应用程序已经设置为使用零作为特殊参考值和设计以某种方式在读取查询结果时立即区分0和NULL。
无论哪种方式,您似乎都面临着一个更大的问题。 UserNotes.UserID
已被允许包含0的现有引用(User.SequenceNumber
列中未找到的值),这意味着UserNotes.UserID
不是正式定义为外键。当没有正式的外键/主键关系时,也没有引用完整性(无论如何从数据库的立场),即使在清理之后,你的UserNotes
表也很容易得到不存在的引用。正在进行。
您应该考虑在数据库级别建立表之间的正式关系。这可能需要对应用程序进行额外的更改(取决于它的设计方式),但这将是一个合理的时间/工作投资,并可能在将来让您头疼。
答案 1 :(得分:0)
它不会破坏Identity属性。
我认为你担心人为改变会产生副作用是正确的。但我认为应用程序方面的问题是关注...您的应用程序还会对您未考虑的记录做些什么。
如果零行是唯一的,并且您对该列没有任何其他约束,则可以插入该行。