如何在Database Design中存储旧版本的ID String？

Question

我正在为实验室建立一个小型数据库。 我们有一些规则为每个Item创建一个ID字符串，所以我不想将它存储在我的数据库中。 问题是有时数据的变化，例如该项的人员响应发生变化，会导致ID字符串的变化。 但我不能纠正印刷文档。 我如何存储该ID字符串的旧版本。 我可能根本就没有改变它，但这会破坏规则。 有什么建议？

Answer 1

扩展达米尔的观点

你说的时候就是“智能钥匙”

我们有一些规则为每个Item创建一个ID字符串

您将获取该项目的名称，可能是类别代码并添加

该人对该项目的回应

因此，如果我负责Beakers的项目ID可能是

玻璃器皿烧杯S页面

当您在数据库中将其作为主键使用时，“代码”将成为“智能密钥”。

这是一种反模式。 像大多数反模式一样诱人。 人们喜欢只关注钥匙并知道它是什么样的东西，它叫什么以及我要求得到更多的东西。 报告或货架标签上的所有信息，只有几个字符。 但是，由于你提到的原因，这是一种反模式 - 它具有意义和意义可以改变。

正如Damir建议的那样，你可以将这个值存储在我们称之为ALTERNATE KEY或CANDIDATE KEY的另一列中......它是唯一的，它可能是PK，但事实并非如此。 您需要对列进行唯一约束，但不需要主键约束。

Answer 2

区分应该唯一标识表中的行的主键和目录中的产品通常具有的某种智能键是很重要的。

对于主键使用自动递增整数 - 这个例外很少。

为您尝试在该智能键中表示的内容添加列，例如： Person ， Project ， Response等。

为该键添加一个单独的列，并像对待表中的任何其他字段一样对待它 - 这应该让习惯这种思维的人感到高兴。

智能密钥在这里用词不当，从数据库设计的角度来看，密钥相当愚蠢。

Answer 3

例如，该项的人员响应发生了变化，导致ID字符串的变化

看起来您实验室中的工作流程已损坏。 ID永远不会改变。 尽量让你的上司注意这一点。