0
4

5 回答 5

1

如果您确实添加了这个 PK，并且还保留了以前的 PK，那么您将需要处理一些数据管理问题。或者也许是您的客户。如果现有用户将升级到新数据库，则摆脱旧 PK 可能不可行。

如果数据用户使用 EmployeeCode（前一个 PK）来识别员工，那么您将必须添加一个约束以确保该字段是唯一的。携带这两个代码将消除您希望的任何性能提升。

如果是我，我会一个人离开。性能提升（如果有的话）将是微不足道的。

于 2012-07-20T20:58:44.163 回答
1

如果您在字母数字字段上创建的索引是表的聚集索引，则性能差异可以忽略不计。根据您的问题，情况将如此，但为了完整性，我想指出这一点。我这么说有两个原因：

  1. 聚集索引是表的物理顺序，因此在查找该索引时，在查询中查找可能从数据页之外的更多数据时，可以对其执行二进制搜索，因为它也是按该顺序物理存储的。
  2. 二进制搜索几乎与您所能获得的一样有效，以免我们忘记统计索引。我之所以这么说是因为整数主键构建的统计索引与搜索一样快，因为从数学上讲，我们知道例如 2 在 1 之后。

因此，在构建字母数字甚至复合键和索引并尝试比较它们与整数键之间的差异时，请记住这一点。就个人而言，我更喜欢使用整数主键，因为我发现它们在极端增长期间随着时间的推移表现更好。

我希望这有帮助。

于 2012-07-20T12:30:12.657 回答
1

我经常使用字母数字主键，绝对没有问题。没有性能问题，您有更广泛的可寻址空间，并且您可以更具表现力/人类可读性。整数键只是一个约定。

通过在移植问题之上添加一个主要的架构更改，再加上您正在为您的项目添加的风险，我会说尽可能地坚持现有的模式。

于 2012-07-20T12:30:56.717 回答
1

不会有性能提升——事实上，除非你知道并且可以证明/衡量你有性能问题，否则改变“让它们更快”通常会导致痛苦。

但是，有人担心您的主键似乎带有含义 - 它是一个国家代码，与一个数字连接。如果员工从美国搬到英国怎么办？如果英国雇佣了第 1000 名员工怎么办？

出于这个原因，我会重构应用程序以使用无意义的主键；无论是 INT 还是 VARCHAR 都不是很重要。

于 2012-07-20T13:09:29.097 回答
0

你偶尔会遇到字母数字主键..我个人觉得它只会让生活变得更加困难..如果你能够改变它并且你想改变它，我会说继续..它会让你以后更容易. 至于它是 FK，您需要小心编写脚本以正确更新所有数据。您可以这样做的一种方法是：

Step 1: Create a new int column for the PK and set Identity Insert to true
Step 2: Add a new int column in your child table and then:
Step 3: write an update script like this:

    UPDATE childTable C
    INNER JOIN parentTable P ON C.oldEmpID = P.oldEmpID
    SET C.myNewEmpIDColumn = P.myNewEmpIDColumn

Step 4: Repeat steps 2 & 3 for all child tables
Step 5: Delete all old FK columns

类似的东西，不要忘记先备份您当前的数据库；）

于 2012-07-20T11:37:03.613 回答