GUID VS 自动增量。 （从舒适的角度来说）
有一段时间，我的系统管理员错误地将我的数据库恢复到了更早的时间点。
3 小时后，我们注意到了这一点，在此期间创建了 80 个新行（具有外键依赖性的自动增量）。
因此，此时我们在两个表中拥有 80 个具有相同 id 的不同客户，需要合并。
我不记得是怎么解决的，但我们解决了这个问题，但花了很长时间。
现在，我正在设计一个新的数据库，我的第一个想法是使用 GUID 索引，尽管这种用例很少见。
我的问题：你的ID这么长，你怎么相处？
我的意思是，当两个程序员谈论一个客户时，可以说：
“嘿。我们的客户端 874454 遇到了问题”。
但是如何使用 GUID 使其保持简单，这确实是一个可能导致一些麻烦和沟通中断的问题。
谢谢
A while a go, my sysadmin restored my database by mistake to a much earlier point.
After 3 hours we noticed this, and during this time 80 new rows (auto increment with foreign keys dependency) were created.
So at this point we had 80 different customers with the same ids in two tables that needed to be merged.
I dont remember how but we resolved this but it took a long time.
Now, I am designing a new database and my first thought is to use a GUID index even though this use case is rare.
My question: How do you get along with such long string as your ID?
I mean, when 2 programmers are talking about a customer, it is possible to say:
"Hey. We have a problem with client 874454".
But how do you keep it as simple with GUID, This is really a problem that can cause some trouble and dis-communications.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您不使用复制，GUID 产生的问题可能比它们解决的问题还要多。首先，您需要确保它们不是聚集索引（至少这是 SQL Server 中 PK 的默认索引），因为您确实会降低插入性能。其次，它们比整数长，因此不仅占用更多空间，而且使连接速度变慢。每个查询中的每个连接。
你将制造一个更大的问题来试图解决一个罕见的事件。相反，想办法进行设置，这样你就不需要花几个小时才能从错误中恢复过来。
您可以创建一个审核解决方案。这样你就可以轻松地从各种失误中恢复过来。并提前编写代码进行恢复。这样当出现问题时就相对容易修复。坦率地说，我永远不会允许在没有某种形式的审核的情况下建立包含公司关键数据的数据库。不这样做就太危险了。
或者，您甚至可以准备一个脚本，将记录移动到临时位置，然后使用新标识重新插入它们（并将子记录上的标识更新为新标识）。您执行过一次此操作，dba 应该创建一个脚本（并将其放入源代码管理中），以便下次您需要执行类似的修复时可以使用它。如果您的 dba 非常无能，他不会创建和保存此类脚本，那么就解雇他并雇用一个知道他在做什么的人。
GUIDs can create more problems than they solve if you are not using replication. First,you need to make sure they aren't the clustered index (which is the default for the PK in SQL Server at least) because you can really slow down insert performance. Second they are longer than ints and thus take up not only more space but make joins slower. Every join in every query.
You are going to create a bigger problem trying to solve a rare occurance. Instead think of ways to set things up so that you don't take hours to recover from a mistake.
You could create an auditing solution. That way you can easily recover from all sorts of missteps. And write the code in advance to do the recovering. Then it is relatively easy to fix when things go wrong. Frankly I would never allow a database that contains company critical data to be set up without some form of auditing. It's just too dangerous not to.
Or you could even have a script ready to go to move records to a temporary place and then reinsert them with a new identity (and update the identities on the child records to the new one). You did this once, the dba should have created a script (and put it in source control) so it is available the next time you need to do a similar fix. If your dba is so incompetent he doesn't create and save these sort of scripts, then get rid of him and hire someone who knows what he is doing.
在大多数视图中只显示前缀。这就是 DVCS 所做的，因为它们中的大多数通过十六进制编码的哈希来识别大多数对象。
（OTOH，我知道在许多圈子里使用 UUID 作为主键很流行；但是要说服我，需要的不仅仅是一些可怕的故事）
just show a prefix in most views. That's what DVCSs do, since most of them identify most objects by a hexcoded hash.
(OTOH, I know it's fashionable in many circles to use UUIDs for primary keys; but it would take a lot more than a few scary stories to convince me)