在数据库中为某些表创建辅助主键

我想在我的某些表中添加“ second_primary_key”，这将是uuid或一些随机的长键。我需要它，因为对于某些表，我不想向我的Web应用程序公开整数。也就是说，在页面“ / invoices”上，我有一个发票列表和一个指向“ / invoices /：id”的链接，其中：id是整数。我不想让用户知道我的系统中有多少张发票，因此我想使用其“ second_primary_key”代替“ / invoices / 123”，从而使URL为“ / invoices / N_8Zk241vNa”

我要隐藏真实ID的其他表也是如此。

我想知道，这是常见的做法吗？实现此目的的最佳方法是什么？

到底该技术叫什么，以便我对此进行搜索？

您可以添加UUID列，但实际上不需要（也不应该）。这是表示层的问题。您不会幻想说将货币值存储为1,999美元以及1999年。

您只需要某种方式可以即时隐藏应用程序的价值。您可以在应用程序本身或数据库视图中执行此操作。

由于我们只在谈论一个单一的值，因此也许请看一下诸如AES或类似方法的2种加密方式-越轻便越好。

散列可能是另一种可能性-这取决于您是否要取回发票编号，因为散列是一种方法。

在关系数据库建模中，拥有“替代主键”是众所周知的概念，它被称为“替代键”，有时也称为“辅助键”。“潜在主键”的集合称为“候选键”。参见https://beginnersbook.com/2015/04/alternate-key-in-dbms/

实施此操作的方式完全取决于您，特别是如果您想隐藏记录的总数。没有“最佳方法”，如果希望ID是否区分大小写，希望在打印的发票上可读，则应检查要求，例如允许的或有用的字符集，最大长度。必须能够正确无误地在电话上将其驱散，依此类推。

大多数发票都有发票编号，大多数会计规则要求该编号是连续的，否则会计可能不会在年度结果上签字，或者IRS（或您所在国家的类似名称）可能希望在您的标签上进行全面审核。

用户可以从发票编号中推断出您服务了多少客户，或者您更改了发票编号策略之前已有多长时间。

数据库中存储了多少张发票无法衡量您的发票总数。还有其他发现方法，包括向商会要求您提供年度报告。

但是，我会将发票锁定在用户登录屏幕后面，因此并非每个人都可以要求它。然后，在用户登录时，他们可以使用ajax方法来请求其未结清的发票等。这可以保护您的数据，通过ajax隐藏URL（通常没人会费心查看ajax请求构建方式的详细信息） ，您可以控制数据的显示和提供方式。

您也许可以为此使用hashid，它专门用于解决这种情况。

它将您的数据库ID编码为短哈希（类似于YouTube视频的URL），并且不需要您在表中添加任何辅助键。

您可以创建另一个唯一键，但不能。没有给出的原因。有更简单的隐藏表大小的方法。

N_8Zk241vNa表中每行的存储成本为12个字节，而索引中的存储成本甚至更高。这对于您的需求而言是非常浪费的。

加密整数id不会浪费空间，并且在运行时几乎没有成本。如何执行取决于您的编程语言和/或数据库。

请注意，使用AES时，您将获得128位整数，这意味着base64中有22个字符，可能比您想要的更多。像DES或3DES这样的块大小为64的密码可以为您提供11个字符，就像您想要的一样。

对不同的表使用不同的键。

如果您只需要隐藏表大小，则可以对所有表使用通用顺序。请注意，如果许多表中频繁插入，则可能会成为瓶颈。使用诸如Hibernate和Hi-Lo算法之类的方法，此问题就消失了。

恕我直言，无法创建两个不同的主键。当然，您可以将该uuid放入数据库中，以使其作为当前主键的“别名”。您可以在具有唯一约束的那列上放置索引，但是主键（从本质上来说）是单个表中的单个。可以有复合主键，但这不是您想要的。

因此，我建议将其放在那里，但只能与索引一起使用。您可以创建处理组件以通过PK以及其他唯一列查询数据。处理“ / invoices / ...”的请求时，只需检查参数-如果它是整数，则搜索ID，否则搜索uuid。或者，当ID搜索未找到任何内容时，您可以将uuid搜索作为后备。

关于生成一些“随机”的uuid：为什么不像“获取ID，添加常量，转换为十六进制”之类的东西。ID的惰性将提供uuid的唯一性，对于普通凡人，十六进制数更难读取+添加常量将避免像00000001这样的uuid。

如果两个键都指向同一事实，并且它们永远不会发生冲突。为什么不使用某些标量函数从原始密钥派生另一个密钥，该标量函数会创建原始密钥的自定义哈希码。

或者，您可以创建一个附件映射表，该表将存储密钥的两个版本。该表将充当字典来查找辅助键。

根据我的理解，键是隐式索引，添加索引越多，插入速度就越慢。

针对您的特定用例的另一种方法是，您无需创建数据库和应用程序，而只需创建到发票的自定义路由，因此/ invoices /：f（id）其中f（id）是id的一部分功能。

定制路由负责将请求映射到正确的操作服务器端。

这是一种完全可以接受的做法，也称为“备用键”（AK）。基本上，AK是另一个唯一索引或唯一约束。

您甚至可以根据AK创建外键约束。

一个可能的用例就像您所解释的那样：您在一个不断增加的标识号上具有群集的PK，但是您不希望此号被显示或用作搜索条件，因为它很容易被猜到。因此，此外，您还有一个随机的唯一标识符或参考号作为AK，这就是您提供给用户的ID

有几种键/索引。主键是一个特殊的唯一索引，正如答案所说，您当然可以创建另一个唯一键。我同意，除非有充分的理由，否则最好不要公开数据库内部信息。

由于问题与发票和编号有关，因此研究会计行业如何期望发票编号看起来可能是值得的：http : //smallbusiness.chron.com/assign-invoice-numbers-52422.html

具有作为主键的内部ID和带有应用程序/客户可见发票编号的另一个唯一字段的内部ID似乎很麻烦。但是当客户想采用一种新的发票编号方案时，情况并非如此。在那种情况下，您不会打扰其他表中的内部ID及其关系来重新编号整个蜡球。您将按原样保留内部ID，然后重新编号非内部发票编号。

理想情况下，您应尽量不要将表与可能更改的键/外键绑定在一起，并使内部表和关系对应用程序层透明。

去吧。

这与博客文章等通常具有的“ slug”字段没什么不同-一种独特的方式来引用与主键分开的数据库记录，适合在URL中使用。我从未听说过有人反对这些。