问题标签 [indexing]

如果我有这样的查询：

我在该EmployeeTypeId字段上有一个索引，SQL Server 是否仍然使用该索引？

随着对应用程序的域模型对象的更改，希望让人们对保持 Lucene 索引保持最新的想法。

有问题的应用程序是一个使用 Hibernate 的基于 Java/J2EE 的 Web 应用程序。我目前的工作方式是 Hibernate 映射模型对象都实现了一个通用的“可索引”接口，该接口可以返回一组记录在 Lucene 中的键/值对。每当执行涉及此类对象的 CRUD 操作时，我通过 JMS 队列将其发送到消息驱动的 bean 中，该 bean 在 Lucene 中记录对象的主键和从 Indexable 对象的 index() 方法返回的键/值对假如。

我对这个方案的主要担心是 MDB 是否落后并且无法跟上即将到来的索引操作，或者如果某种错误/异常阻止对象成为索引。结果是某个时间段或较长时间段的过期索引。

基本上我只是想知道其他人为这种事情想出了什么样的策略。不一定要寻找一个正确的答案，但我正在想象一系列“白板”之类的想法，让我的大脑思考替代方案。

我的数据库中有以下表，它们具有多对多关系，由一个连接表表示，该连接表具有到每个主表的主键的外键：

• Widget：WidgetID (PK)、标题、价格
• 用户：用户 ID (PK)、名字、姓氏

假设每个 User-Widget 组合都是唯一的。我可以看到关于如何构造定义数据关系的连接表的两个选项：

1. UserWidgets1：UserWidgetID (PK)、WidgetID (FK)、UserID (FK)
2. UserWidgets2：WidgetID（PK、FK）、UserID（PK、FK）

选项 1 有一个主键列。但是，这似乎没有必要，因为表中存储的唯一数据是两个主表之间的关系，而这种关系本身可以形成唯一键。因此导致选项 2，它具有两列主键，但丢失了选项 1 具有的一列唯一标识符。我还可以选择在第一个表中添加一个两列唯一索引（WidgetID、UserID）。

两者在性能方面是否有任何真正的区别，或者有任何理由更喜欢一种方法而不是另一种方法来构建 UserWidgets 多对多表？

I'm writing a manual and some important keywords are repeated in several pages. In the project's index I defined the keywords like this:

It works but instead of the title the dialog shows the keyword and the name of the project repeated three times.

Here's how it looks: http://img54.imageshack.us/img54/3342/sokeywordjs9.png

How can I display the tile of the page that contains the keyword in that dialog? I would like to show like this:

Thanks

在 SQL Server 2005 中，查询分析器多次告诉我要在已经具有聚集索引的表的主 ID 列上创建非聚集索引。遵循此建议后，查询执行计划报告查询应该更快。

为什么同一列（具有相同排序顺序）上的非聚集索引比聚集索引更快？

今天早些时候，当我看到 Stackoverflow 中一个令人惊讶的功能时，我打算问一个问题。当我写我的问题标题时，stackoverflow 向我建议了几个相关的问题，我发现已经有两个类似的问题。那太棒了！

然后我开始思考如何实现这样的功能。我将如何按相关性排序问题：

1. 词数较多的问题与新问题匹配
2. 如果匹配数相同，则考虑单词的顺序
3. 标题中出现的词具有更高的相关性

那将是一个简单的工作流程还是一个复杂的评分算法？也许是为了增加召回率？有没有实现这个功能的库？你还会考虑哪些其他方面？也许杰夫可以回答自己！你是如何在 Stackoverflow 中实现的？:)

我有一个要索引的文件（具体来说是 fasta 文件），以便我可以快速找到文件中的任何子字符串，然后在原始 fasta 文件中找到该位置。

在许多情况下，使用 Trie 或子字符串数组很容易做到这一点，不幸的是，我需要索引的字符串是 800+ MB，这意味着在内存中执行它们是不可接受的，所以我正在寻找一种合理的方法来创建它磁盘上的索引，内存使用量最少。

（编辑澄清）

我只对蛋白质的标题感兴趣，所以对于我感兴趣的最大数据库，这是大约 800 MB 的文本。

我希望能够根据输入字符串在 O(N) 时间内找到确切的子字符串。这必须在 32 位机器上可用，因为它将被运送给随机的人，他们预计不会拥有 64 位机器。

我希望能够针对一行中的任何断字进行索引，直到行尾（尽管行可能有几 MB 长）。

希望这可以阐明需要什么以及为什么给出的当前解决方案没有启发性。

我还应该补充一点，这需要在 java 中完成，并且必须在各种操作系统的客户端计算机上完成，所以我不能使用任何特定于操作系统的解决方案，它必须是一个编程解决方案。

如果您在存储过程中创建一个临时表并希望在其上添加一个或两个索引，以提高针对它所做的任何其他语句的性能，最好的方法是什么？Sybase 是这样说的：

"创建索引时表必须包含数据。如果创建临时表并在空表上创建索引，则 Adaptive Server 不会创建柱状图和密度等列统计信息。如果在创建索引后插入数据行，优化器的统计数据不完整。”

但最近一位同事提到，如果我在与实际使用临时表的存储过程不同的存储过程中创建临时表和索引，则 Adaptive Server 优化器将能够使用它们。

总的来说，我不太喜欢增加一点价值的包装程序，所以我实际上并没有测试这个，但我想我会把问题放在那里，看看是否有人有任何其他的方法或建议？

如果我按顺序在列（A、B、C）上创建索引，我的理解是即使我只搜索（A）或（A 和 B）或（ A 和 B 和 C)，但如果我只搜索 (B)、或 (C) 或 (B 和 C)，则不会。它是否正确？

我们有一大堆“搜索”客户、客户等的查询。您可以按名字、电子邮件等进行搜索。我们以下列方式使用 LIKE 语句：

全文索引在场景中是否有帮助？我们使用的是 SQL Server 2005。