sql-server - 在 SQL Server 中存储 URL

Question

使用 SQL Server 我想在表中存储 URL 列表。此外，我还要求不希望任何 URL 在表中出现超过一次。

这表明我希望将 URL 作为表的主键，但由于 URL 的长度，这在 SQL Server 中是不可能的。 SQL Server 有一个限制，即可以索引的字符字段的最大长度为 900 个字符，而根据规范的 URL 可能是无限的，并且实际上 IE 支持高达 2k 的 URL，因此 900 太短了。

我的下一个想法是使用 HashBytes 函数创建 URL 的哈希值，以用作要索引的列。在这种情况下，两个不同的 URL 可能会哈希为相同的值(不太可能但有可能)，因此我无法使用唯一索引。

针对该表的大部分处理将是插入，这是我希望优化的性能。

我的想法是拥有一个 URL 列和一个哈希值列，并在哈希值上创建一个非唯一索引。

然后，我将为插入创建一个触发器，如果​​插入的哈希值 = 现有的哈希值并且插入的 URL = 现有的 URL，它将回滚插入。我希望查询优化器能够使用索引首先找到哈希值匹配的记录，然后不必进行全表扫描来尝试匹配 URL。

我走在正确的轨道上还是有更好的方法来解决这个问题？

Answer 1

有更好的方法。

创建一个新字段int，将其设置为identity并自动递增。一般来说，使用字符串作为索引是非常糟糕的，一方面，如果您想稍后更改 URL，无论出于何种原因，您都必须更新所有外键，这很快就会变得非常可怕。如果您也有数十亿个 URL，您的数据库大小将会膨胀，一个简单的 int 字段可以缩小大小。

我有时认为我可以使用其他字段作为主键，但选择 int 字段，我很高兴我进一步这样做了。

除非我误解了这个问题。您预计多久插入一次 URL？您很可能低估了数据库的能力。他们可以非常快地执行大量查询。做一些测试!没有理由可以在插入 URL 之前使用快速 select 语句检查 URL。

或者您可以随意插入，然后在稍后执行批处理作业以删除重复项。

或者您可以将它们排队等待插入。

我会保持简单。我想您可能会对数据库执行基本查询的速度感到惊讶，它们在设计时就考虑到了这一点。

在我看来，你最大的问题是如何存储 URL，有很多东西可以用多种方式解释。例如，为什么不将域(COM、CO.UK 等)进一步规范化并单独存储域扩展名，并使用一个表将域与后缀/前缀/协议(protocol)链接起来，而不是包含域(COM、CO.UK 等)。还记得http://www.example.com可以与 http://example.com 不同在某些边缘情况下。

如果您确实标准化到更高的级别，那么您的约束和唯一性都将变得管理起来更加复杂。

有很多值得思考的地方!确保你设计得很好。