0

一段时间以来，我一直在寻找一个令人满意的答案，对我的特定问题更具体一些，但还是有用的。我是否只是没有看正确的地方，我不知道，但这里有：

我正在从应用程序中提取数据，然后对其进行操作并发送到我自己的服务器。在提取的数据中，最初在应用程序的数据库中是一个自动递增的标识符。我刚才检索到的这个标识符的一个例子是955534861。不自动增加我的主键并且只使用我知道并且将始终保持唯一的值不是更好更有效的设计，还是我应该研究诸如代理键之类的概念？

提前致谢。

4

4 回答 4

2

您描述的情况类似于我的主要工作，即维护数据仓库。我们从其他系统获取数据并将其存储。

发生在我们身上的事情是这些“其他系统”发生了变化。这导致“其他系统”的新版本可能会复制先前系统的唯一标识符。我们通过在我们的数据仓库中向该记录添加一些内容来处理这个问题，以保证它的唯一性。它可能是标识源系统的字段，也可能是日期。它永远不是自动生成的数字。

如果这种情况有可能发生在您身上，您可能希望扩大您的选择范围。

于 2013-07-03T16:17:38.160 回答
1

如果模型中有自然键，则不能通过创建代理键来替换它。

您只能添加一个代理键并保留现有的自然键，这有其优点和缺点，如此处所述。

于 2013-07-03T20:43:42.187 回答
0

这会有点书呆子，但请耐心等待：

只要键值是唯一的，它就会发挥作用。但是为了性能，您最好希望该键值尽可能短。

GUID 是常用的，因为它们在统计上极不可能被重复。但这是以牺牲大小为代价的：它们有 128 位长，这使得它们比机器字长。要比较两个 GUID（在排序时必须重复进行，或者向下迁移索引的 b 树）将需要多个处理器指令来加载和比较值。当它们缓存到内存中时，它们会消耗更多的内存。

自动递增键值的优点是

  • 它们保证是独一无二的。代理索引值仅被预测为唯一的。
  • 因为它们将在其基础数据类型的范围内具有完整的值覆盖，所以可以使用最紧凑的可能类型。这使得更小的索引和更有效的比较操作
  • 因为可以使用尽可能小的类型，所以可以在单个数据库页面上存储更多的索引值，这意味着在搜索或加入该值时更有可能获得缓存命中。这意味着性能会——在所有其他条件相同的情况下——会更好一些。
  • 在大多数数据库中，自动递增的键在数据库引擎中工作，因此生成它们的开销非常小。
  • 如果您在键值上使用聚集索引，则新记录插入不太可能需要随机磁盘查找，并且更有可能在预读期间被读取，因此如果您基于该键执行任何类型的顺序处理或查找，它可能会运行得更快。
于 2013-07-03T16:11:38.400 回答
0

主键，通常是一个自动递增的 ID，也是 MySQL 用作行标识符的，所以它应该单独存在。如果您需要由应用程序生成的辅助键用于其他目的，您可能希望将其添加为另一列并UNIQUE在其上添加索引。

在其他具有适当行标识符机制的数据库中，这不是问题。

于 2013-07-03T16:03:39.507 回答