-3

我想知道我是否将 10 个条目插入到 SQL Server 表中。如果我然后删除其中一个,id/index 会相应改变吗?

例子:

1 | Simon Cowell | 56 years
2 | Frank Lampard| 24 years
3 | Harry Bennet | 12 years

如果我删除#2,Harry Bennet 的索引会变为 2 吗?

谢谢 :)

编辑:对不起,我的愤怒,度过了糟糕的一天。是的,我应该自己研究一下,我应该被否决。我不求什么,我只想说对不起:|

4

4 回答 4

2

不,您可以根据需要设置触发器或逻辑来执行此操作;但是,它不会自动执行此操作。

于 2012-11-20T14:41:09.493 回答
2

由于您似乎将“id/index”混为一谈,让我们稍微谈谈关系数据库上下文中的主键和索引。

分配给 SQL 数据库中一行的“id”或主键是该行的唯一标识符。它可以由一列或多列组成。(当涉及多个列时,它被称为“复合”或“多部分”键。)主键实际上应该只是用于寻址行的唯一句柄:主键不应该包含任何有关由该行表示的实体的信息,特别是如果该信息有可能是可变的;一个例子是具有后缀的零件编号,该后缀代表零件的金属类型;如果该金属可能从钛变为 unobtainium,例如,该零件号将作为主键的错误选择;最好有另一列来存储金属的类型,而不是将金属类型的后缀作为主键的一部分。“有意义的”主键在遗留的非关系数据库中可能有意义,但在关系数据库中它们应该被避免。

当寻求强制主键的唯一性时,数据库引擎可以利用索引来快速测试键值是否存在。它可以使用二进制算法来查找值,避免需要逐行扫描实际数据“蛮力”,寻找值。 但是引擎在幕后使用的索引来帮助它进行主键管理与主键本身是不同的

如果您有一个简单的连续整数作为主键,那么它们的数量是无限的,因此当分配给它的行已被删除时,当它变得可用时,无需重用整数。因此,关系数据库引擎不会自动尝试重用它,并且当数字序列中的“间隙”由删除。其他表中的许多其他行可能正在引用这些值,并且让它们可变会造成混乱或极大的低效率。

Hashing algorithms are another very efficient way a database engine can quickly test for the existence of a key value. It computes the location in the hashed-file where the key would be if it did exist, and then looks there for it. The rows are stored in no particular order, so such schemes are optimized for instant finding of records in a large table, not for culling records that have a common characteristic, such as all customers in zipcode 10023.

于 2012-11-20T15:07:40.240 回答
0

不,它不会自动更改

于 2012-11-20T14:41:47.933 回答
0

不,它不会。希望这就是您所希望的答案。对于任何自动生成的标识符(例如 IDENTITY 列),您应该尽可能忽略数据类型并将其视为身份信息的不透明“blob”。

它在插入期间被分配,您可以将其用于交叉引用目的,但它是数字的事实不是您应该使用或依赖的。它只是行的稳定标识符。

于 2012-11-20T14:43:05.577 回答