我一直在研究使用GUID作为数据库中的主键.到目前为止,职业选手似乎超过了缺点.但是,我看到GUID可能不是我想要的一点.
在我的应用程序中,用户应该能够基于用户友好的ID识别对象.因此,例如,如果他们想要在不输入全名的情况下获得特定产品,他们可以使用产品的ID.对于类似的东西,GUID并不容易记住.
我一直在考虑的解决方案是同时使用GUID和自动递增整数.GUID将是行的主键,而自动递增的整数将是应用程序的过滤函数使用的索引.但是,所有SQL SELECT,UPDATE,DELETE语句都将使用GUID.
我想使用GUID的主要原因是在合并两个数据库时防止冲突.如果Database#1和Database#2都有Product#2,则导入器脚本必须更改ID以及引用它的所有外键.使用GUID,我只需要更改表本身的用户友好ID,而外键将使用每个导入记录唯一的GUID,因此无需修改即可使用.
所以,我的问题是:是否有任何重大问题(除了GUID字段的大小和简单的页面碎片)与自动递增整数索引和GUID主键?
我总是倾向于在我的数据库中使用代理主键.也就是说:这些主键在问题域中没有实际意义,因此,这些主键永远不会暴露给用户.(如果此代理主键是GUID类型或标识,我不在乎;这取决于要求).
如果您说用户应该能够基于用户友好的ID识别对象,那么,我认为这个用户友好的ID是属于您的"问题域"的值.这意味着,此ID应该确实是表中的属性,但不应将其用作表中的主键.
这也允许您轻松修改这种用户友好ID的值(如果这是必要的话),而不必担心修改相关的外键.