在 SQL Server 2005 中更改唯一键的影响
在 SQL Server 2005 中更改唯一键有什么影响
我有一个表，其中一个主键 ID int 和 4 个字段的复合唯一键。 但由于我的项目的性质，复合键的键（字段）之一不断变化。
有人发现频繁更改组合键字段有任何问题吗？
What is the impact of changing a Unique key in SQL Server 2005
I am having a table one primary key ID int and composite unique key for 4 fields.
But due to nature of my project one of the keys(fields) of the composite key keeps on changing.
Does anyone find any problem in changing the field of composite key that often?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
涉及维护，因为所有非聚集键都指向聚集键或指向行（如果您有堆（没有聚集键的表）），
因为聚集键在任何时候都保存表的所有数据（本质上它就是表）您对非聚集键进行更改，聚集键将被更新，反之亦然
there is maintenance involved since all nonclustered keys point to either the clustered key or to the row if you have a heap (table without a clustered key)
Since the clustered key holds all the data for the table (in essence it is the table) whenever you make changes to the nonclustered key the clustered key will be updated and vice versa
该指数将需要进行一些重组。
这是 ACID 中 C 的一部分：当 UPDATE 完成时，一切都已完成并除尘。
此外，任何使用该数据的索引视图也需要更新，这也是“C”的一部分。
如果它没有聚集，那么这就是关于它的。
我不会太担心它，除非它每秒发生很多次......
The index will need some reorganisation.
This is part of the C in ACID: When your UPDATE completes everything is done and dusted.
Also, any indexed views using the data will need updated too, again part of the "C".
If it's not clustered then this is about it.
I wouldn't worry about it too much unless it's happening many time a second...
我只是确保添加一些代码来监视唯一约束违规。 你不应该遇到问题，但如果你经常改变它，我会说你面临更大的风险。
I would just be sure to add some code to be watchful of unique constraint violations. You shouldn't run into a problem, but if you're changing it that often, I would say that you run a greater risk.