支持大下拉菜单的最佳方式
假设我有一个可以通过在下拉列表中指定某些值来限制的报告。该下拉列表引用了带有 > 的表格30,000 条记录。我认为这对于填充下拉列表是不可行的！那么，在这种情况下，让用户能够选择值的最佳方式是什么？这些值实际上没有类别，即使我按值的第一个字母细分（通过一些嵌套下拉列表的情况），仍然可能留下几千个条目。
处理这个问题的最佳方法是什么？
Say I have a report that can be restricted by specifying some value in a dropdown. This dropdown list references a table with > 30,000 records. I don't think this would be feasible to populate a dropdown with! So, what is the best way to provide the user the ability to select a value given this situation? These values do not really have categories and even if I subdivided (by having some nesting dropdown situation) by the first letter of the value, that may still leave a few thousand entries.
What's the best way to deal with this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
搜索，不要分类。
您可以将控件显示为一个简单的文本框，当用户输入几个字符时，您可以弹出一个类似自动完成的下拉列表来选择最终值。 这是用于自动完成的 jQuery 插件的链接。
Search, don't categorise.
You can display the control as a simple text box, and when the user types in a few characters, you could pop up an autocomplete-like dropdown to select the final value. Here's a link to the jQuery plugin for autocomplete.
我真的不会拥有 30,000 个元素的下拉菜单。 GUI 应该让用户更容易，而不是更难。
如果您除了按字母顺序之外没有其他方法对数据进行分类，则您不限于使用仅使用第一个字符的两阶段方法。使其依赖于前两个字符。
这将在第一个下拉列表中最多为您提供 676 个（假设仅包含 alpha），在第二个下拉列表中为您提供（平均）44 个。
我们实际上采取了两种方法来解决这个问题。 BIRT（我们使用的）允许级联参数，每当您更改第一个下拉框时，这些参数都可以轻松运行第二级查询。
然而，我们的一些客户对漂亮的 GUI 东西的关心绝对为零（当然，除了漂亮的 9 点 Verdana 的输出和用于安抚管理的漂亮图表）。他们更喜欢自由格式的文本输入字段，只需输入“SYS_PAX_%”即可更改查询。
当然，这些客户确切地知道他们的数据库中有哪些数据，并使用有助于通过 SQL
LIKE子句进行分类的值。其他人则更喜欢搜索功能。I really wouldn't have a 30,000 element drop-down. The GUI is supposed to make it easier on the user rather than harder.
If you have no other way to categorise the data other than alphabetically, you're not restricted to using a two-stage approach with just the first character. Make it reliant on the first two characters.
This would give you at most 676 (assuming alphas only) in the first drop-down and (on average) 44 in the second.
We've actually taken two approaches to this problem. BIRT (which we use) allows for cascading parameters which can easily run that second-level query whenever you change the first drop-down box.
However, some of our customers care absolutely zero for nice GUI stuff (other than the output of nice 9-point Verdana and beautiful charts to placate management, of course). They prefer a free-form text entry field where they can just type in
"SYS_PAX_%"to change their queries.Of course, these are the customers that know exactly what data is in their database and use values which lend themselves to categorisation with SQL
LIKEclauses. Others prefer the ability to search.如果您从性能角度而不是可用性角度提出问题，我会考虑使用实时列表方法，当您向上或向下滚动时，仅按需加载列表项的子集。如果用户快速单击列表下方（即中间位置），它将加载与该位置相对应的另外 10 个元素。渲染时间和加载时间都会快得多。
类似于分页，但“流畅”。
If you're asking from a performance perspective rather than a usability perspective I would consider using a live-list approach that loads only a subset of the list items on demand as you scroll up or down. If the user clicks down the list quickly, to say the middle, it will load another 10 elements corresponding to that position. Both render time and load time will be much faster.
Like paging, but 'fluid'.
大约两年前，我对 ASP.NET 下拉框也有同样的问题。
相信我，甚至不要尝试。使用上面的自动完成建议。我发现显示 5000 条以上的记录往往会使浏览器崩溃。
只是我的2分钱。
I had this same question about 2 years ago concerning a asp.net dropdown box.
Trust me, don't even try it. Use the auto complete suggestions above. I've found that displaying anything above 5000 records tends to crash the browser.
Just my 2 cents.
+1@pax。不过我还是想看到 30K 的下拉菜单！ :)
@JustAProgrammer，也许你可以做一个文本框，人们可以在其中输入他们要查找的内容的开头，并且你可以在他们输入时进行过滤。
+1 @pax. Still i'd like to see a 30K dropdown! :)
@JustAProgrammer, perhaps you could do a text box where people can type in the beginning of what they are looking for and you can filter as they type in.
最好有上面建议的自动完成下拉菜单。但它需要用户对开始时的条目类型有一定的了解。如果用户熟悉数据，那就去吧。
或者，如果您可以对数据进行分类，那么您可以首先从类别开始，然后根据选择，您可以使用实际值填充依赖下拉列表，这些实际值将是原始值的子集。
Auto complete drop down as suggested above is best to have. But it will require the users to have some idea about the type of entries to start with. If the users are familiar with data, go for it.
Alternatively, if you can categorize your data, then you can start with the categories first and then based on the selection you can populate the dependent drop down with actual values which will be a subset of original values.