一阵子，我的系统管理员错误地恢复了我的数据库到更早的点。
3小时后，我们注意到了这一点，并在此期间创建了80个新行（自动递增与外键依赖）。
所以在这一点上，我们有80个不同的客户在两个需要合并的表中使用相同的id。
我不记得是怎么回事，但我们解决了这个问题，但花了很长时间。
现在，我正在设计一个新的数据库，我的第一个想法是使用GUID索引，即使此用例很少。GUID VS自动递增。 （在舒适的智慧）
我的问题：你怎么和这样长的字符串作为你的ID相处？
我的意思是，当程序员2在谈论一个客户，就可以说：
“嘿，我们与客户874454有问题”。
但你如何保持它与GUID一样简单，这实际上是一个可以带来一些麻烦和DIS-通信的问题。
感谢
的GUID可以创造更多的问题比解决的，如果你没有使用复制。首先，你需要确保它们不是聚集索引（这至少是SQL Server中PK的默认值），因为你真的可以减慢插入性能。其次，它们比整数更长，因此不仅占用更多空间，而且使连接速度变慢。每个查询中的每一个连接。
您要创建试图解决一个难得的一次出现更大的问题。相反，想办法设置一些东西，这样你就不用花几个小时从错误中恢复过来。
您可以创建一个审计解决方案。这样你可以很容易地从各种失误中恢复过来。并提前写代码来做恢复。当事情出错时，修复起来相对容易。坦率地说，我永远不会允许包含公司关键数据的数据库在没有某种形式的审计的情况下建立起来。这太危险了。
或者你甚至可以有一个脚本准备去记录移动到一个临时的地方，然后用一个新的身份重新插入（和更新子记录的身份到新的一个）。你这样做了一次，dba应该创建了一个脚本（并将它放在源代码控制中），以便在下次需要执行类似修复时可用。如果你的dba非常无能，他不会创建并保存这些脚本，然后摆脱他并聘请一个知道他在做什么的人。
只是显示在多数意见的前缀。这就是DVCSs所做的事情，因为大多数DVCS通过十六进制编码哈希来识别大多数对象。
（OTOH，我知道这是在许多圈子用于主键的UUID时髦，但它会采取比一些可怕的故事多了很多说服我）
“审计的形式”是什么意思？你的意思是数据库完整日志写入谢谢 – fatnjazzy
可以设置数据库来记录对特定审计表中关键表的更改。它通常还包括进行更改的用户的ID和日期。这用于监管/财务审计目的，并能够轻松修复不良数据更改。没有数据库会通过日志记录自动执行此操作（至少不在易于访问的级别）。这是一个必须设置为数据库设计一部分的系统。 – HLGEM