Database design 如何向用户解释哑主键的优势？

主键吸引力

我的老板（以及用户）希望主键是复杂的/智能的/有吸引力的控制号码（有点像社会保险号码或信用卡号码格式）

我只是用零填充主键（在视图中），以满足他们的愿望，使控制数字复杂、智能和吸引人。但他们希望它是：前2位数字作为客户代码，然后4位数字作为年份，然后最后4位数字作为给定年份该客户的交易编号，然后在下一年流动时将客户的交易编号重置为1。每个客户的交易从1开始。e、 g.WM20090001、WM20090002、BB2009001、WM20100001、BB20100001

但由于我想让事情尽可能简单，我放弃了在主键中嵌入他们建议的智能，我只保留主键自动递增，而不管客户和年份。但为了让它看起来不单调（他们确实坚持将主键作为智能控制编号），我让主键看起来很智能，在查看查询时，我将客户端代码和四位数年份代码放在八个零填充自动递增键（即WM200900000001）的前面。有关自动递增主键的排序信息

保持主键自动递增，而不考虑任何其他信息，我们可以在他们编辑记录时保留其他潜在的副作用问题，例如，如果他们错误地在WM上输入交易，那么他们会将客户端代码编辑为BB，如果我们使用智能主键，WM customer的主键在其控制编号中会有缺口。更糟糕的是，用户将要求这些间隙的后续记录向上移动到这些间隙，并重新调整（递减）后续记录的主键，而不是让控制编号具有间隙/孔

• 您如何处理这些用户请求（合理或其他）
• 你同意他们的要求吗
• 或者继续使用哑主键，向他们解释使用非常智能/复杂的主键的后果，并教育他们使用哑主键的显著优势

附言

可引用的引号（）：

“如果你先闭嘴 时间用户问什么是他们的 合理的要求，事情会顺利的 最后好多了。”

---

我赞成你的轻蔑。你必须满足自己的需要。如果可能的话，我会解释说，在头脑中保留或理解数据记录是计算机前的需要，人们应该相信机器和系统。。。嗯，不是这样的措辞，但你明白了。但我常常只是点头，给他们他们认为他们需要的东西——但不是他们想象中的桌子钥匙。但在查询级别

---

事实上，我有史以来最好的数据库工作——我目前的工作——基本上是因为我之前的那个家伙没有得到这个。他会无休止地和经理们争论愚蠢的数字，并坚决拒绝提供任何其他信息。我所要做的就是承诺“不要那样做。”

是否存在一些键的串联，从而生成一个自然合成的唯一键？我想不会，否则你就不会问这个问题了

用户不想知道感兴趣的记录存储在哪个气缸/气缸块/气缸盖上，同样，他们也不需要知道哑主键；这是一个实现细节。使用哑主键有很好的理由，但这不是业务原因。将哑键的实现细节隐藏在业务级别有意义的外观后面

---

解释他们是对的可能不会对你有利。解决客户明确的需求，这是你的工作。

在我看来，最终用户不需要知道不同类型主键的优缺点

---

对最终用户来说，数据库中数据的精确设计和实现应该被视为一个黑匣子。归根结底，这个黑匣子的输出是他们所需要的正确格式的数据：用户不需要或不必知道所讨论的特定字段是PK还是由PK生成的。

根据爱因斯坦的观点，一切都应该尽可能简单，但不能比这更简单。在旁观者眼里，简约有时是存在的。如果用户认为智能钥匙比哑钥匙简单，那么在视图中，您可以很好地容纳它们

通过继续在基表中使用哑键，可以避免使用智能键时最终出现的一些陷阱

---

知识就是力量。数据也是如此。当数据共享时，电源共享。当权力被分享时，政治就发生了。外交是工作的一部分

如果他们打算将生成的id用作唯一id，那么最好将其设为主id。我没有在自动递增键上嵌入客户代码和年份，只在视图中发生（仍然将主键保留为简单的自动递增整数），我只是让它成为一种错觉。因此，类似于鼻涕虫的暗指就是这样的一种初级教育key@Shawn这是有道理的。但我认为它可能并不适用于所有情况——例如，存在一个真正的性能问题，主键应该是数字。感谢techrepublic链接，twas信息丰富。我真的希望你明白，“保持沉默”并不意味着“然后让客户告诉你如何做你的工作”，而是“利用输入更好地定义他们的要求”。给他唯一的钥匙，即“smart:，但对于所有内部工作，如联接、导出/导入、开发等，都有哑键。我相信OLTP数据库中的每个表，除了哑键之外，还必须有业务唯一键。这清楚地定义了表中存储的内容，允许构建高效的提取，等等，这就是我的意思。但更多的是埃鲁迪