php - 在创建存储在数据库中的短 URL 算法时，有哪些潜在问题需要解决

Question

我知道创建一个短 url 算法并不像对 URL 进行哈希处理然后将哈希分解为自身的某个增量版本那么容易。尽管从外部的角度来看，这似乎正在发生。我读过几篇关于这个想法的文章，也看过几篇文章的实际应用。但似乎没有人担心 future 的验证。

所以我在这里试图找出如何使用 PHP 解决这个问题，并找到至少可以避免常见问题的方法。从数据库冲突到除总体存储和数据库大小之外可能需要担心的任何其他问题。

我肯定会面临的一个问题是，我正在创建的服务正在从我的伙伴正在创建的另一项服务中获取用户端 URL，因此在每个用户的基础上，我们正在跟踪那里的短 URL，因此它可能的多个用户最终可能会使用完全相同的长 url，但我们需要为每个提供 URL 的用户提供不同的短 url id。想一想几个用户正在分享最近走红的 youtube 视频。

那么创建一个不会同时面对许多 bash 的短 url 算法的最佳策略是什么，它将允许我使用一些可能的短 url 查询我的数据库，看看它们是否已经存在。

更好的是有一些方法我可以通过 mySQL 功能创建唯一的 id，这将在概念循环中直到一个是唯一的并因此为这个原因创建？

我知道我是在求救，这是一个相当开放的问题。但我试图在深入构建过程之前巧妙地思考，后来才发现我搞砸了。在确保我对此采取半理智的方法之前，我有点需要一些意见。

Answer 1

您可以使用 this用 PHP 制作的短 URL 算法 - 它为同一 url 生成四个不同的“散列”。

像这样创建一个表

id |    original_url        |   short_url
------------------------------------------
1    http://www.google.com/     tm5kxb

当用户输入要缩短的 URL 时，您将使用文章中的函数并收到一个包含四个不同哈希值的数组。然后您可以使用如下查询:

SELECT id FROM {your_table} WHERE short_url = "{a_hash_from_the_function}"

如果查询没有返回结果，则表示没有匹配项，您可以使用这个。如果查询返回结果，只需使用数组中的另一个散列，看看它是否存在，等等。

阅读整篇文章，因为作者在底部解释了如何使您的哈希值更加不可预测。我建议使用不同于 md5() 的散列算法，但您必须自己进行试验。 :)