嗨。
我正在建立一个展示大量产品的网站。
我希望URL对人类友好并针对搜索引擎进行优化，因此我希望将过滤产品反映在URL中。
例如，用于过滤产品的可能URL路径是
website.com/Type/Car/Country/Usa/Manufacturer/Ford/Year/2007
所以这是我的问题，因为我总是想弄清楚如何根据这些字符串过滤数据库，这是一种使用字符串作为主键绝对有意义的情况吗？ />就性能而言。
我已经阅读了这个stackoverflow问题的答案
Strings as Primary Keys in SQL Database
那里的人说它取决于字符串的大小和其他因素，但在我看来，在这种情况下，因为我总是要在不同的表中搜索字符串，所以这个字符串是主要的。另一种方法是将整数设置为主键，但我仍然会搜索非主字符串并从中找出主键。从我对数据库的理解来看，这是一个坏主意，因为它们以一种搜索主键的速度比搜索任何其他字段的方式存储数据。
我正在使用MS SQL Server 2005.谢谢。< / p>
答案 0 :(得分：5)
由于某些原因，URL会产生错误的主键 - 其中一个原因是每次插入新记录时，您的页面都会碎片化，因为它必须对整个表进行物理重新组织并按字母顺序将新记录保留在其中。索引URL列，您将获得所需的所有查找性能。每次插入时重建索引都比在某些方面重建表更好。
另一个（正如Josh所指出的）是URL 高度相似，因此比较将非常缓慢（与int相比） - 对于两个项目 - 2007和{在2008内{1}}你必须覆盖很多地方 - 56个字符（加上website.com/Type/Car/Country/Usa/Manufacturer/Ford/Year/的三个字符）才能找到唯一的字符。
答案 1 :(得分：5)
不，字符串比较将明显慢于整数比较（这是选择主键时考虑的主要性能影响）。你想要的是字符串上的索引，它提高了搜索字符串列的性能。主键不是存储预先计算数据以搜索列的唯一方法。
答案 2 :(得分：3)
请，不。
如果您正在搜索字符串，请索引该列。但老实说，保持整数主键要好得多。您不知道是否需要更改字符串。
此外，比较和加入字符串要慢得多。在多个表和一堆行中，这会变得很痛苦。
我从来没有见过我喜欢的字符串PK的实现。请使用整数并索引列。生活对你来说会好得多。
答案 3 :(得分：1)
我想指出主键和聚簇索引之间存在差异。 PK可以由非聚集索引维护，在这种情况下，插入新项目时不会重新排列整个表格。
我建议在代理键上使用聚簇索引，但是如果你想要一个唯一的索引用作主键，那就没关系。您可以在任何唯一索引上使用外键，无论它是否为群集，以及它是否为主键。
对于PK使用自然键（如你所描述的）有相当强烈的论据。只是在它下面没有聚集索引，因为CIX几乎不应该在这样的字符串上。
罗布
答案 4 :(得分：1)
如果您查看SO网址，您会注意到他们不实际存储了密钥的字符串，但是项目（问题）ID。 URL是带有人类可读描述的装饰，但这与映射完全无关。因此，打开网址Should I use strings as primary keys for a Web site that's big on SEO?与打开Should I use strings as primary keys for a Web site that's big on SEO?相同，这与打开https://stackoverflow.com/questions/1258198
相同所以你看，http请求和url映射中发生的事情不是数据库中存储的内容。数据库使用int ID，这是出于以前答案中已经解决的明显性能和存储原因。
答案 5 :(得分：0)
您可能需要考虑将字符串的哈希值用作索引/键，而不是字符串本身。这将有助于避免在查询中进行代价高昂的字符串比较。
数据是否比URL方案更长？您可能需要字符串的简单，整数，主键和辅助键/索引。这样，如果你必须使用字符串索引回溯你的步骤，外键关系仍然有效。
您是否考虑过如何规范化URL字符串以确保正确映射到记录？例如是年==年和福特/ 2007 == 2007 /福特？这些路径是否应映射到同一记录？
答案 6 :(得分：0)
我认为这里有一个字符串作为PK是可以的，因为汽车制造商的名单很小（200？）。即使是carmodels的名单也不是那么大（20000？）。 如果您进一步深入细节，那么您将不再对字符串键感到满意。每辆车的轮辋/轮胎清单真的很大。
您将遇到的问题是您无法在网址“Alfa Romeo”中找到该名称。为了让人性化，我会将其改为“Alfa-Romeo”并将其作为PK和URL，但保留原始名称作为可读名称。汽车模型的问题变得更糟。
尤其是法国人对这款“雷诺Mégane”非常不满意。您需要查看“Unicode decomposition”
我不喜欢这样做的替代关键是，汽车的名称不会经常改变，但是你的代理钥匙会。
答案 7 :(得分：0)
我不同意整数键总是最好的。当然，通过整数查找会更快。但是，实际上，如果您必须执行的访问将始终或几乎总是一个文本值，那么如果您有查找记录ID，那么它会快得多，这几乎无关紧要。如果只是你事先知道中奖彩票号码，那么你就可以购买带有这个号码并且很有钱的票。毫无疑问是真实的陈述，但如果您没有提前获得中奖号码，则无用。
所以真正的问题是：您需要在您的数据库中存储什么，以及您如何访问它？如果99％的访问都是“获取URL并查找记录”，那么使用URL或从URL中获取的内容可能是一个好主意。
我反对它的主要论点并不是它是一个字符串，而是一个结合了许多不同事实的字符串。你有没有关心这些作品？就像，你想说，“找到我所有的福特”吗？如果是这样，那么将“福特”卡在主键的中间是一个非常糟糕的主意。找到所有福特的唯一方法就是全文顺序搜索，在键的中间寻找字符“福特”。丑陋。最好有一个单独的“make”字段，你可以搜索。
我不知道您的应用程序，但我怀疑从URL到记录不是唯一的访问权限。是不是有某种浏览或搜索功能，用户可能会说，“找到我所有不到10年的敞篷车”或其他一些？如果是这样，您确实需要将数据分解为单个字段才能进行搜索。
此外，您在检索此网址时获得了哪些数据？您是只获得一条记录并显示它，还是有许多记录悬挂在它上面？如果有相关记录，那么如果URL是“开始”记录的主键，那么所有这些相关记录也必须将该大URL保存为外键。这可能会变得混乱。在决定索引之前，您应该考虑数据库的整体结构 - 您需要哪些表以及它们如何相关。 （嘿，这听起来像是为我的书添加无耻插件的好地方，“数据库设计的Sane方法”，我在其中讨论设计考虑因素以及您应该做出设计决策的顺序。）
一个细节，但可能是一个大问题：你真的需要那里的细分名称和值吗？也就是说，不是将URL设为“website.com/Type/Car/Country/Usa/Manufacturer/Ford/Year/2007”，而不是仅仅是“website.com/Car/Usa/Ford/2007”？这将消除大量冗余文本。顺便说一句，如果你只是在处理一个网站，所以你的所有网址都是“website.com”，那么你肯定不需要将它存储在每个记录中。哦，订单是否重要？有人可以提供URL“webiste.com/Year/2007/Type/Car/Manufacturer/Ford/Country/Usa”并获得相同的信息吗？如果是这样，情况会变得复杂得多。
那里有除汽车以外的东西吗？比如，有没有“website.com/Type/Pet/Kind/Dog/Breed/Poodle”或其他一些？ （或者省略标签，“/ Pet / Dog / Poodle”。）如果是这样，使用URL的通用方案看起来比尝试将其分解为单个字段的更具体的方案要好一些。也许