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

经常提到的一点是处理系统与用户价值的问题。在我们的项目中，用户和系统值存储在一起。例如...

我们有一个模板列表。

1, <system template>

2, <system template>

3, <system template>

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

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

4, <user template>

...和...

5, <user template>

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

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

THEN !! ...我们在新系统模板中发现错误，需要对其进行更新...问题是如何？我们无法使用ID6更新记录(因为我们可能将其插入为9或者999，因此我们必须使用其他某种机制来识别记录)

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

在红色角落(速度)。

我们仅以5000(或者其他值)开始用户ID，并以10000(或者其他值)测试数据。这将使我们能够修改系统值，并测试它们直到下一个ID范围的下限。

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

缺点...如果我们没有选择足够大的范围，可能会用光价值！

在蓝色的角落(可扩展性)...

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

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

缺点..实现起来比较复杂。 (许多到一个可更新的视图等)

我丰满正视的第一选择，但寻找一些弹药支持我！

有没有人对这些方法有什么想法，甚至我们错过了？

解决方案

回答

也许我没听懂，但是我们不能将GUID用作ID并仍然将用户和系统数据一起存储吗？然后，我们可以通过(不可更改的)GUID访问系统数据。

回答

我建议对第二个参数进行修改，以将系统值和用户值存储在一个表中。 GUID以这种方式非常可靠。

另一个想法：使用我们为系统值提供的任何基于文本的ID(不是必需的GUID)，它是由随机字符串或者基于某种用户值定制逻辑的字符串生成的。

另一个想法：使用第一种方法，但是用标记扩展表，该标记显示值是系统还是用户。也许这是最简单的。好的，我们必须编写某种机制来更新正确的系统值，但这可以轻松完成。

回答

我认为GUID应该不会出现任何问题。

如果要避免这种情况，请使用标志：

ID int
  
  template whatever
  
  flag enum/int/bool

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

如果我们想更新系统值，则仅询问按ID排序的系统值，它将显示实际插入顺序(我们应该为ID输入bigint或者其他内容，以确保其不完整，并且它不会使已删除的ID恢复正常工作)。有了这个清单，x。记录是x。插入的系统值。

回答

Biri基于文本的ID的+1定义一个" template_mnemonic"基于文本的列，并将其作为主键。当我们将其插入时，这将是一个已知值，开发人员将决定该值(或者自动生成该值)，并且无论有多少用户指定的模板，我们始终可以通过其助记符来引用该模板。它还允许用户为其模板使用有意义的命名约定。

回答

我从来没有遇到过使用GUID作为数据库ID的问题(包括性能或者开发TDD和单元测试)，并且我从事过一些大型工作。如果我们想了解更多有关使用GUID(以及可能涉及的GOTCHAS)作为主键的信息，请在这里和这里看看，但是我不推荐我们使用它，因为安全地移动数据和DB同步变得像早上刷牙:-)

对于上述问题，我建议第三列(如果可能)表明模板是基于用户还是基于系统，或者我们至少可以在插入系统模板并为其保留清单时为系统模板生成GUID。它们，以便我们需要更新模板时，只需在DEV，UAT和/或者PRODUCTION数据库中定位相同的GUID，而不必担心会覆盖其他模板。尽管可以随意选择所有系统或者用户模板，而无需将它们分成两个表，这第三栏会派上用场(这是过分的恕我直言)。

希望对我们有所帮助，

罗布·G

回答

我认为有更好的第三种解决方案。
令我惊讶的是，我们要将两个不同的东西存储在同一张表中，最好创建两个单独的表，一个用于用户模板，另一个用于系统模板。然后，我们也许可以在两个表上创建一个视图，以使它们在应用程序中显示为单个对象。
显然，我不了解应用程序，出于多种原因，这可能对我们来说是不可能的，但是我认为这比GUID更整洁，并且比ID范围更安全(严重的是，不进行ID范围设置会咬你一天)