最后一个查询可能会执行得很糟糕。数据库内的字符串比较可能非常慢,并且根据“命中”的数量,它可能会对性能造成巨大的拖累。如果那不关心你,那很好。如果公司数据未规范化到其自己的数据库表中,则尤其如此。
只要用户知道他正在查找的公司,那么我会在一些流行的 JavaScript 库中识别一个现有的 JavaScript 组件,该组件提供一个搜索文本字段和一个显示匹配结果的动态下拉列表,这将是一种有效的机制。但是,如果他们可能会查找名称的一部分,您可能希望使用 '%A%'。例如,如果我正在寻找 IBM Rational, LLC。当我搜索“Rational”时,我希望它显示在结果中吗?
无论哪种方式,请注意您的表现,如果有意义,将公司中的数据缓存在位于数据库前面的服务器上的查找服务中。此外,请确保您不会响应每次击键,但有 500 毫秒左右的超时时间,以允许用户在进入服务器和搜索之前输入多个字符。另外,我不建议将所有公司名称带给客户。我们一直在寻求减少从浏览器页面遍历服务器的大小和频率。当表单加载时(甚至在幕后)等待 24k 公司名称出现在客户端时,更短、更快、非常具体的查询将执行得足够好,对我来说似乎更有效。再次测试它并确定最适合您的用例的性能特征。
这些是我在大数据项目中使用的技术,例如从 100,000 多个用户中搜索用户。我们的代码是一个自定义的 Dojo 小部件 (dijit),我没有看到如何直接使用 dijit 代码来完成它,但是 jQuery UI 提供了自动完成小部件。
还要在此查询上使用带有文本字段的限制,以便下拉列表仅提供所有匹配项的子集,从而迫使用户进一步细化查询。