在 URL 缩短器中使用双射字典
我正在创建一个新的 URL 缩短器，并且已经读到需要一个双射函数。所以，我找到了 Jon Skeet's BiDictionary （优秀）并想知道我如何在 URL 缩短应用程序中使用它。目前，我对数据库 ID 列进行 Base36 编码以创建缩短的 URL 并将完整的 URL 存储到表中。这工作正常，但我不明白为什么我需要使用双射函数？我是否将数据库中的值存储到双射字典中？我目前拥有的功能足够吗？使用双射词典有什么好处？
I am creating a new URL shortener and have read that a Bijective function is what is required. So, I found Jon Skeet's BiDictionary (excellent) and wondered how I'd use this within the URL shortener application. Currently, I Base36 encode the database ID column to create my shortened URL and store the full URL into the table. This works fine but I'm lost as to why I need to use a Bijective function? Do I store the values from the database into the Bijective Dictionary? Is what I currently have functional enough? What would the benefits be of using a Bijective Dictionary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不太确定我是否完全理解您的问题...
如果我理解正确，您已经创建了一个具有唯一 ID 和 URL 的查找表。
您的缩短的 URL 是 Base36 编码的 ID。
让我们看一下用例：
创建缩短的 URL
意味着在您的实现中检查表中是否已有该 URL（简单，只需返回 Base36 编码的 ID）。
否则，只需创建一个新条目并返回新 ID 的 Base36 编码。
查找完整的 URL
将 Base36 值解码为 ID，在表中查找 ID，如果找到则返回完整 URL。
所以基本上你已经创建了一个双射函数（双向 1:1 对应）——只是在两个方向上工作而没有任何损失的函数，因此对于表中给定的 URL 来说是完全可逆的。 Base36 编码/解码也是完全可逆的，所以这也是一个双射函数 :-)
你提到的 Jon 的 BiDictionary 是内存缓存的良好基础（建议直写），所以您可以尽可能避免数据库往返。
Bidictionary使用Dictionary，而对于可由多个线程访问的缓存，我强烈建议使用ConcurrentDictionary。在您的情况下，不需要 Jon 实现中的List<>部分，因为您始终会有 1:1 对应关系。为了更快地查找，您可以使用 Base36 编码值作为键...Not really sure that I understand you question fully...
If I understand you correctly you have created a lookup table with a unique ID and a URL.
Your shortened URL is the Base36 encoded ID.
Let's look at the use cases:
Create a shortened URL
means in you implementation check whether you already have that URL in the table (simple, just return the Base36 encoded ID).
Otherwise just create a new entry and return the Base36 encoding of the new ID.
Lookup the full URL
Decode the Base36 value to an ID, lookup the ID in the table and return -if found- the full URL.
So basically you have created a bijective function (a bidirectional 1:1 correspondence) - just something that works in both directions without any loss, thus fully invertible regarding the given URLs in your table. The Base36 encoding/decoding is fully invertible too so that is a bijective function too :-)
The
BiDictionaryfrom Jon you mention would be good base for an in-memory-cache (recommend write-through) so you can avoid the DB roundtrip where possible. TheBidictionaryusesDictionarywhile for a cache which can be accessed by multiple threads I would strongly recommend usingConcurrentDictionary. In your case theList<>part from Jon's implementation is not needed since you always would have a 1:1 correspondence. For faster lookup you could use the Base36 encoded value as a key...