作为我们当前数据库工作的一部分，我们正在研究如何处理更新数据库的过程。
反复提出的一点是处理系统与用户价值的问题;在我们的项目中，用户和系统val存储在一起。例如......
我们有一个模板列表。
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，因此我们必须使用其他一些机制来识别记录）
因此，我们为此提出了两种可能的解决方案。
我们只需启动5000（或其他值）的用户ID并以10000（或其他值）测试数据。这将允许我们对系统值进行修改并将其测试到下一个ID范围的下限。
优势......快速且易于实施，
缺点...如果我们不选择足够大的范围，可能会耗尽价值！
我们分别存储，系统和用户数据，使用GUID作为ID并使用视图合并两个列表。
优势......可扩展......无需考虑数据库大小。
缺点..实施起来比较复杂。 （多对一可更新的视图等。）
我正好为第一个选项做准备，但是找一些弹药支持我！
有没有人对这些方法有任何想法，甚至是我们错过的方法？
答案 0 :(得分：1)
我建议使用第二个修改，将系统和用户值存储在一个表中。 GUID以这种方式非常可靠。
另一个想法：使用任何基于文本的ID（不是必需的GUID），它为系统值提供，并由随机字符串或基于某种用户值的自定义逻辑的字符串生成。
另一个想法：使用第一种方法，但使用标志扩展表，该标志显示值是系统还是用户。也许这是最简单的。好的，你必须编写某种机制来更新正确的系统值，但它可以很容易地完成。
答案 1 :(得分：1)
+1 - 定义基于“template_mnemonic”文本的列并使其成为主键。当您按原样插入它时，这将是一个已知值，开发人员将决定它（或自动生成它），并且无论用户指定的模板数量多少，您始终都能通过其助记符引用模板。它还允许用户为其模板设置有意义的命名约定。
答案 2 :(得分：1)
我从来没有遇到过使用GUID作为我的数据库ID的问题（性能或开发 - 包括TDD和单元测试），而且我已经研究了一些相当大的问题。如果您想了解有关使用GUID（以及可能涉及的潜在GOTCHAS）作为主键的更多信息，请查看here，here和here，但我不能高度推荐它因为安全地移动数据，DB同步变得像早上刷牙一样容易： - ）
对于上面的问题，我会建议第三列（如果可能）指示模板是基于用户还是基于系统，或者您至少可以在插入时生成系统模板的GUID并保留现有的列表，这样，如果您需要更新模板，您可以在DEV，UAT和/或PRODUCTION数据库中定位相同的GUID，而不必担心覆盖其他模板。第三列可以随意选择所有系统或用户模板，而无需将它们分成两个表（这是过度的恕我直言）。
我希望有所帮助，
Rob G
答案 3 :(得分：0)
也许我没有得到它，但你不能使用GUID作为ID并仍然将用户和系统数据放在一起？然后，您可以通过（不可更改的）GUID访问系统数据。
答案 4 :(得分：0)
我认为GUID不会产生任何问题。
如果你想避免它，那么使用一个标志：
ID int
模板
flag enum / int / bool
标志显示实际值是系统值还是用户值。
如果您想更新系统值，请仅询问按ID排序的系统值，它会显示实际的插入顺序（您应该有一个bigint或ID的东西，以确保它不得到满，它不会使删除的ID恢复工作）。用这个列表x。记录是x。插入系统值。
答案 5 :(得分：0)
我认为有更好的第三种解决方案。 令我感到震惊的是，您在同一个表中存储了两个不同的东西，并且最好创建两个单独的表，一个用于用户模板，另一个用于系统模板。然后，您可以在两个表上创建一个视图，使它们显示为应用程序的单个对象。 显然我没有完全了解你的应用程序，这可能因为各种原因而不可能，但我认为它比GUID更简洁，比ID范围更安全（严重的不做ID范围）有一天咬你）