0

我正在使用的当前数据库中的表很少，其中有两个以上的 ID 列，其中一个具有自动增量，用于索引另一个唯一 ID 列，其中 ID 由程序员生成并存储用于索引。我以前从未见过这样的场景。他们这样做的答案是，当他们合并在一个数据库服务器上生成的数据时，可以很容易地与另一个数据库合并而不会发生冲突。因为他们之间几乎没有关系。

如果您使用单个自动递增 ID，则会出现问题，

  • 一组记录将被插入到主表中，并在其外部表中引用相同的 id。如果这些数据合并到另一个已经存在一些数据的数据库中，它们可能会与该数据库中自动生成的 ID 冲突。

  • 例如，TBL_1 是在其他 10 个表中引用的主表，因此在转储到另一个数据库时必须保留在 TBL_1 中生成的 id。可能有一些记录已经具有相同的 ID，存在。然后发生冲突。

  • 否则，如果您将增量过程留给新数据库，那么这 10 个引用的表将失去与该表的完整性。

这是正确的使用方式吗？（这是一个现有的系统，不是我创建的）。

谢谢你的建议。

4

2 回答 2

0

我在自动增量列中看不到任何好处。我理解您的问题的方式是，所有引用都是使用显式生成的 ID 完成的。我相信出于这个原因在应用程序级别明确生成 ID 是完全有效的，但我会让这些生成的 ID 成为唯一的 ID，以使系统更简单、更容易理解。并且它将防止将来的修改意外使用错误的 ID，即无法在合并到另一个数据库中后继续存在的 ID。

于 2012-12-13T14:02:04.953 回答
0

没有魔法：

  • 要么你需要使用一个全局唯一标识符（例如 GUID 或某种全局可见的“ID 服务器”），它们不会在不同数据库之间发生冲突。
  • 或者您需要将您的 ID 从一个“命名空间”转换为另一个，递归地包括所有外键。

顺便说一句，虽然 GUID 确实会在InnoDB clustered table中到处乱扔行，但自动增量实际上会产生类似的效果（只是更依赖于 INSERT 的时间）。并且不要忘记聚集表中的二级索引是昂贵的（它需要包含 PK 的副本，并且可能导致双重查找）。

除非您有自动递增 ID 的特定原因（例如保持子 FK 苗条），否则只需使用应用程序生成的 ID 作为 PK。如果你让它在全球范围内独一无二，那将避免任何 ID 转换的需要并显着简化合并过程......

于 2012-12-13T14:38:52.483 回答