通过字符串 id 而不是数字 1 在实体处检索答案

【问题标题】：Retrieving at entity by a string id instead of numerical one通过字符串 id 而不是数字 1 在实体处检索
【发布时间】：2017-01-01 07:14:21
【问题描述】：

在我自己建立的网站上，文章的链接如下所示：

my_website.com/article/33/some-article
my_website.com/article/213/another-article

假设大约有 10 000 个。现在它们仅由 id 检索，当已经检索到文章时，id 之后的部分会即时添加到 url。我想把它们改成这样：

my_website.com/article/some-article
my_website.com/article/another-article

因此，我需要为“article_friendly_title”添加一个索引。它可能有 50 个字符长。我想知道，这会带来很多开销吗？它会减慢从数据库文章过程中获取的速度吗？我猜它会明显变慢。尽管如此，有很多网站都有相同类型的产品或文章网址，而且他们似乎对此没问题。

【问题讨论】：

【解决方案1】：

大多数数据库实现使用二叉树作为索引列，这意味着索引列可在 O(log(n)) 时间内搜索。在最坏的情况下，该算法会在 14 次比较中找到 10,000 行的数据库中是否存在搜索词。

如果您熟悉二分搜索，或者曾经编写过算法，它只会调用大于、小于或等于比较。

索引列的数据类型几乎没有区别，因为在固定长度（甚至 50 个字符）的字符串上计算大于、小于或等于的操作被视为 O(1).

如果您还没有想到，另一个考虑因素是确保“友好文章名称”列的名称是唯一的。

【讨论】：

如果我在“友好的文章名称”列上有一个索引，一个 db 可以确保它的唯一性，不是吗？
问题是，一篇文章将有 50 个字符长的“友好文章名称”列，因此它的索引将是 -- 多长时间？至少 50 个字节，或者 100 个字节。而不是 4 字节长的整数索引。这不是很大的开销吗？
在纯理论上，被比较的字符串的长度仍然被认为是O(1)，因为字符串的长度不会随着数据库的大小而改变。实际上，这在比较非常长、非常相似的字符串时可能会有所不同。但请记住，比较字符串“看看新蝙蝠侠”和“我为什么跳过变形金刚 6”只需要 1 个字节的比较（'W' > 'A'）。还要记住，即使您必须将两个字符串的所有 50 个字节比较 14 次，这也是 700 次比较，这可能与比较整数相比无法区分。
严格来说通常不是二叉树，而是B-tree或者B+tree。
我不是指同情时间和复杂性，而是“友好文章名称”索引在数据库中占用的空间。至少要多 10-20 倍，不是吗？