SQL设计 - 如何存储大量的URL

Question

我正在编写一个具有SQL Server后端的应用程序，该后端将存储（除此之外）url。 URLS将映射到用户，并且某些URL可能在不同用户之间是通用的。在没有真正的DBA的情况下，我正在尝试设计一种能够尽可能高效地处理数十万个URL的解决方案。

思路：

1. 创建只有ID，URL

   的表格

   亲：简单，完整。
   CON：将存在重复的URL条目，这将导致表格大于它需要的大小。

2. 将用户和URL分解为单独的表。一个表格包含USER ID和URL ID。另一张包含URL ID和URL的表格。

   Pro：系统中的单个URL，似乎更“企业” Con：在尝试撤回结果时必须加入两个表，并且不确定这种方法的好处是什么？

3. 扩展2的想法，除了真的打破它。所以有一个域表，另一个用于路径/查询字符串。然后，user表将具有userid, domain ID, path ID。

   Pro：url可以共享数据，即使它不相关（意味着，cnn.com/helloworld和nbc.com/helloworld会有不同的域ID，但相同的路径ID ...似乎这在以后运行指标时会有用吗？

   Con：从性能角度来看，似乎是一场噩梦（同样，因为需要连接来提取URL。

有什么想法吗？

Answer 1

我会在设计中执行以下操作：

UserId  UrlId
1       1
2       2
1       1

UrlId  Url
1      http://www.google.com
2      http://www.yahoo.com

如果尚未存在完全匹配，则将您的网址存储在单独的表中，并仅在网址表中创建新条目。如果您有许多常见的URL，这将节省一些空间。您可以更进一步，并按照您的提法添加第三个表格，例如

UrlPathId  UrlId  UrlPath
1          1      /shopping

...然后将UrlPathId绑定到User表。甚至可能更进一步：

UrlPathId  UrlId  UrlQueryString
1          1      ?product=speakers

...再次，从您的用户表中引用它。

Answer 2

听起来您正在描述用户与网址之间的多对多关系。

我强烈建议排除选项1.这不仅会增加大小，而且因为如果您需要更新URL或用户，则每次复制时都必须这样做，而不是一次。< / p>

选择2到3之间更难，因为它更多地取决于如何使用它。 ＃2更加简单化，并且仍然正常化。 ＃3中的功能似乎并没有超过我的复杂性，所以我个人选择了＃2。

编辑：看到乔治的答案后，我完全赞同第一部分。

Answer 3

你真的那么空间吗？除非您需要将URL本身视为一个对象，否则我只会选择1并使用索引覆盖它，如果您对URL有特定的性能要求。

请参阅我在此处处理孤儿网址的其他评论。