数据库表设计 - 使用长列作为主键有什么问题吗？答案

【问题标题】：Database table design - Are there any problems with using a long column as a primary key?数据库表设计 - 使用长列作为主键有什么问题吗？
【发布时间】：2020-08-14 05:43:39
【问题描述】：

请原谅我可能是一个愚蠢或明显的问题 - 我是数据库新手。

我计划将文件路径链接存储到来自 java 的 Derby 数据库中的磁盘媒体文件，但我很好奇设置表的最佳方式。

澄清一下，我不打算将实际媒体存储在数据库中，只存储文件路径。

该表将包含大约 10k-100k 行。

我认为文件路径应该是主键，因为它唯一地标识了每个媒体文件。

设置带有文件路径的表并能够有效搜索（主要是文件名中的子字符串，也包括媒体属性）的最佳选择是什么？

我打算使用VARCHAR(4096)，因为最大 linux 路径长度为 4096 个字符。

以这种方式创建表是否有任何优点或缺点，索引可能是相当长的 VARCHAR 列？你建议我应该如何设计表格？

谢谢！

【问题讨论】：

它不会给 Derby 带来任何特别的问题，但正如其他人在他们的回答中指出的那样，选择替代桌子设计可能是有原因的。

标签： java sql database database-design derby

【解决方案1】：

免责声明：这是一个非常个人的观点，可能很多人会不同意。

您正在考虑使用“自然键”，而我反对使用它们。自然键是对象的现有属性，它唯一地标识它......直到它没有。

这就像我的全名，我在我的国家的身份证号码。这些属性似乎是独一无二的，但问题是它们稳定。它们是可见的现有已知属性；这种可见性使他们容易受到变化的影响。这意味着，它们会及时改变。如果我改名，我会是同一个人吗？

另外，一个键通常用于在某种程度上链接到其他表。一个大的PK对此并不好。但这更像是一个实际问题。

我建议您使用简单的 INT 或 BIGINT 作为主键，并向路径属性添加 UNIQUE 约束。这样你的模型会更灵活。如果媒体被移动到另一个路径，您只需要更新表中的单个值；如果路径是 PK，那么您需要更新与其相关的所有外键。

【讨论】：

谢谢，这很有意义。媒体项目将在另一个表中具有标签，因此这是一个很好的建议。如果媒体文件被移动，我希望标签仍然链接到它。
“如果我改名，我会是同一个人吗？” - 对于程序员论坛来说，这是一个相当哲学的问题...... :-)
@localhost Borges 说我不会是同一个人。维特根斯坦同意了，但出于完全不同的原因……但这是题外话：|

【解决方案2】：

不要使用长字符串作为主键。

使用合成主键。

以下是一些原因：

主键的一个重要目的是支持外键。当您可能只有一个 4 字节整数时，您不想让 4k 字符串潜伏在您的数据库中。
使用主键的另一个重要原因是唯一地找到每一行。我认识的大多数人都不想输入 4k 个字符来识别一行。我打字很快，这对我来说需要时间。而且我确信我会在途中的某个地方打错字。
两个字符串可能仅在第 2017 个字符上有所不同。我不想弄清楚它们是不同的，尤其是当角色是 1 与 l 或 O 与 0 时。

定义一个自动递增/识别/序列主键。您始终可以将 URL 声明为 unique，这样它就不会重复（尽管某些数据库可能不允许索引中使用如此长的键）。

【讨论】：

非常感谢。对于我的媒体索引数据库，我会不时重新扫描驱动器以查找新文件。每次要重新扫描时都必须在整个数据库中搜索每个文件的文件路径似乎效率低下，但我认为这是不可避免的。我应该做些什么来加快检查现有文件的速度吗？我想我只是 SELECT 整个文件表并从中搜索内存，对于 100k 文件现在应该不是问题，但我想知道数百万或数十亿文件的最佳做法是什么。
@localhost 。 . .您可能会发现散列路径很有帮助。将其存储为单独的列，并将其用于匹配行的初始搜索。