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

时间:2008-08-13 12:23:38

标签: database

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

反复提出的一点是处理系统与用户价值的问题;在我们的项目中,用户和系统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并使用视图合并两个列表。

优势......可扩展......无需考虑数据库大小。

缺点..实施起来比较复杂。 (多对一可更新的视图等。)


我正好为第一个选项做准备,但是找一些弹药支持我!

有没有人对这些方法有任何想法,甚至是我们错过的方法?

6 个答案:

答案 0 :(得分:1)

Biri基于文本的ID的

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

答案 1 :(得分:1)

我从来没有遇到过使用GUID作为我的数据库ID的问题(性能或开发 - 包括TDD和单元测试),而且我已经研究了一些相当大的问题。如果您想了解有关使用GUID(以及可能涉及的潜在GOTCHAS)作为主键的更多信息,请查看hereherehere,但我不能高度推荐它因为安全地移动数据,DB同步变得像早上刷牙一样容易: - )

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

我希望有所帮助,

Rob G

答案 2 :(得分:1)

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

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

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

答案 3 :(得分:0)

我认为GUID不会产生任何问题。

如果你想避免它,那么使用一个标志:

  

ID int

     

模板

     

flag enum / int / bool

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

如果您想更新系统值,请仅询问按ID排序的系统值,它会显示实际的插入顺序(您应该有一个bigint或ID的东西,以确保它不得到满,它不会使删除的ID恢复工作)。用这个列表x。记录是x。插入系统值。

答案 4 :(得分:0)

我认为有更好的第三种解决方案。 令我感到震惊的是,您在同一个表中存储了两个不同的东西,并且最好创建两个单独的表,一个用于用户模板,另一个用于系统模板。然后,您可以在两个表上创建一个视图,使它们显示为应用程序的单个对象。 显然我没有完全了解你的应用程序,这可能因为各种原因而不可能,但我认为它比GUID更简洁,比ID范围更安全(严重的不做ID范围)有一天咬你)

答案 5 :(得分:0)

也许我没有得到它,但你不能使用GUID作为ID并仍然将用户和系统数据放在一起?然后,您可以通过(不可更改的)GUID访问系统数据。