我正在学习系统设计。第一个用例是URL缩短服务。我读到我们可以在RDBMS中存储short_url,long_url对。因为根据需求，我们应该能够将short_url映射到long_url(这样就可以将其发送到调用客户端)，也应该能够从long_url映射到short_url(这样就不会再缩短现有的long_url)。我的问题是如何在RDBMS中有效地完成这些映射/查找。简单的回答是，短url上的索引和长url上的索引都得到了维护。我想探讨一下它的细节，比如在RDBMS中，这两种情况下的索引技术是什么。
从你的描述中我可以收集到，你实际上并没有"映射"。任何东西，你只需要存储一个URL和它的简短等效。
所以排除任何其他信息，我倾向于使用
create table URLs (
Id int identity(1,1),
LongURL varchar(200),
ShortURL varchar(20),
CreateDate datetime default (getdate())
)
create unique clustered index IdxShortURL on URLs (ShortURL)
create nonclustered index IdxLongURL on URLs (LongURL)
首先，您将查找给定短url的长url，因此这是唯一索引和集群，数据库可以直接查找它并返回完整的url
您可以使用LongURL上的非聚集索引检查是否存在已经存在的URL。
编辑
扩展索引策略-这实际上取决于预期的使用情况。通常在监视查询执行计划之后才会出现正确的索引策略。
是的，两者都是类似的字符列，但是-这是我的假设-长URL将主要使用短URL查找远比相反的情况，即，我有短URL，我需要查找长URL -在这种情况下，短URL是同义表的'Id'，它是通过你访问其他信息的关键。
通过将短URL指定为唯一的和聚集的，表中的数据在物理上按短URL排序，并且当使用短URL查找一行时，等效的长URL立即作为索引叶级的一部分可用，并且单个seek操作可以检索它。
相反，如果URL已经存在，你不想添加它，检查URL的存在将通过查找长URL来完成，因此在该列上单独索引就足够了;即使您需要检索短URL作为此查找的一部分，因为URL是唯一的，它只是一个单一的书签查找，是非常快速和有效的。
嗯，但希望这符合你的意图。