默认数据库 ID；系统和用户价值

Question

作为我们当前数据库工作的一部分，我们正在研究处理更新数据库的过程。

反复提出的一个问题是处理系统与系统的问题。用户价值；在我们的项目中，用户和系统值存储在一起。例如...

我们有一个模板列表。

1, <system template>

2, <system template>

3, <system template>

这些在应用程序中映射到枚举 (1, 2, 3)

然后用户进来并添加...

4, <user template>

...和...

5, <user template>

然后..我们发布升级..并作为我们升级脚本的一部分插入...

<new id> [6], <new system template>

然后！！...我们在新的系统模板中发现了一个错误，需要更新它......问题是怎么办？我们无法使用 ID6 更新记录（因为我们可能已将其插入为 9 或 999，因此我们必须使用其他机制来识别记录）

因此，我们为此提出了两种可能的解决方案。

在红色角落（速度）......

我们简单地将用户 ID 设为 5000（或其他值），并在 10000（或其他值）测试数据。这将允许我们对系统值进行修改并测试它们直至下一个 ID 范围的下限。

优点...快速且易于实施，

坏处...如果我们没有选择足够大的范围，可能会耗尽值！

在蓝色角落（可扩展性）...

我们分别存储系统和用户数据，使用 GUID 作为 Id，并使用视图合并两个列表。

优点...可扩展...对数据库大小没有限制。

坏处..实施起来比较复杂。（多对一可更新视图等）

---

我完全支持第一个选择，但正在寻找一些弹药来支持我！

有人对这些方法有什么想法，甚至是我们错过的方法吗？

Answer 1

我从来没有遇到过使用 GUID 作为数据库 ID 的问题（性能或开发 - 包括 TDD 和单元测试），并且我已经处理过一些相当大的问题。看一看 这里, 这里 和 这里 如果您想了解有关使用 GUID（以及涉及的潜在问题）作为主键的更多信息 - 但我强烈推荐它，因为安全地移动数据和数据库同步变得像早上刷牙一样简单： -)

对于上面的问题，我建议使用第三列（如果可能）来指示模板是基于用户还是基于系统，或者您至少可以在插入系统模板时生成 GUID 并保留以下列表：现有的，这样如果您需要更新模板，您可以在 DEV、UAT 和/或 生产数据库中定位相同的 GUID，而不必担心覆盖其他模板。第三列会派上用场，但可以随意选择所有系统或用户模板，而不需要将它们分成两个表（恕我直言，这是矫枉过正）。

我希望这有帮助，

罗布·G

Answer 2

我建议使用第二种方法并进行修改，将系统值和用户值存储在一个表中。GUID 在这种方式下是相当可靠的。

另一个想法：使用任何基于文本的 ID（不必要的 GUID），该 ID 是您为系统值提供的，由随机字符串或基于用户值的某种自定义逻辑的字符串生成。

另一个想法：使用第一种方法，但使用一个标志扩展表，该标志显示值是系统值还是用户值。也许这是最简单的。好吧，你必须编写某种机制来更新正确的系统值，但这很容易完成。

Answer 3

+1 为 Biri 基于文本的 ID - 定义一个“template_mnemonic”基于文本的列并将其设为主键。当您插入时，这将是一个已知值，开发人员将决定它（或自动生成它），并且您始终能够通过助记符引用模板，无论有多少个用户指定的模板。它还允许用户为其模板制定有意义的命名约定。

Answer 4

也许我没明白，但是你不能使用 GUID 作为 Id 并且仍然将用户和系统数据放在一起吗？然后您可以通过（不可更改的）GUID 访问系统数据。

Answer 5

我不认为 GUID 应该造成任何问题。

如果你想避免它，那么使用一个标志：

ID 整数

模板无论如何

标志枚举/整数/布尔

Flag显示实际值是系统值还是用户值。

如果您想更新系统值，则仅要求按 ID 排序的系统值，它会显示实际的插入顺序（您应该有一个 bigint 或 ID 的东西，以确保它不会变满并且它不会让已删除的 ID 恢复工作）。有了这个列表，x.记录是x。插入的系统值。

Answer 6

我认为还有更好的第三种解决方案。让我印象深刻的是，您在同一个表中存储了两个不同的内容，并且您最好创建两个单独的表，一个用于用户模板，一个用于系统模板。然后，您可以创建两个表的视图，使它们在您的应用程序中显示为单个对象。显然，我对您的应用程序没有完全了解，并且由于多种原因，这对您来说可能是不可能的，但我认为这是一个比 GUID 更简洁的解决方案，并且比 ID 范围更安全（说真的，不要做 ID 范围，它会总有一天会咬你一口）