使用多个搜索位置搜索 box/field 设计
Search box/field design with multiple search locations
不确定这个问题是否更适合不同的 StackExchange 站点，但是，这里是：
我有一个搜索页面，可以搜索许多不同类型的东西。所有（目前）都需要为每种类型的搜索提供不同的输入字段。例如，可能会搜索学校或学区名称、class 名称、工作人员电子邮件地址等。我有 9 个不同的 'type' 搜索，每个搜索页面上都有自己的输入字段.我已经连接了其中一个（用户名和 UID 搜索），但我想知道将这些全部放入一个输入字段（因此是一个单独的搜索）在设计（用户友好）和性能方面是否有意义
这些不同的类型当然是一些不同的表，所以它要为每个类型查询很多次不同的时间，就为了一次搜索。
有什么想法吗？还是我应该保持原样？我可以添加一个下拉菜单来选择不同的 'type' 搜索，但这看起来同样混乱。当我不在主搜索页面（也恰好是主页）时，我已经为我的导航栏做了这个
我的项目是用金字塔框架Python编写的。
我可以看到它被发布到 UX SE（ux.stackexchange.com 我想？）网站，或者他们可能已经有一个问题涉及这样的事情。但就我个人而言，我可能倾向于使用下拉菜单 select 或使用不同的类型，或者保持单独的搜索不变。而且我认为我会更倾向于下拉框 - 对于搜索界面来说，这对我来说似乎不合理。
我想一个问题是 - 是否可以期望从同一搜索中的多个表中获得结果？如果是这种情况，我可以看到实施您的统一搜索想法，即使这意味着查询多个表。或者某种附加界面，您可以在其中 select 您想要查询的表。
如果应用程序发生变化，您的搜索界面会发生什么变化？这是一个非常重要的方面。您是否添加其他搜索类型？
搜索 returns 匹配查询字符串。结果集可以包含来自不同类型的不同实体。然后您的 search/resultset 界面可以应用基于实体类型或实体方面的过滤（示例：Ebay、Amazon）
从 Solr/elasticsearch 和附加项目中学习。分面搜索是用户现在习惯的。与编写跨多个表的复杂查询相比，分离数据存储 (RDBMS) 和全文搜索引擎的概念更加强大和可扩展。任何较大的互联网公司（Ebay、Facebook、Amazon、Instagram）都可以讲述有关使用这些模式的故事。将存储与搜索分开可提供可扩展性和灵活性。
与其编写 query/search 代码，不如学习如何从任何数据存储中为这些搜索引擎提供数据。我保证，这会更强大、更有趣。
不确定这个问题是否更适合不同的 StackExchange 站点，但是，这里是：
我有一个搜索页面，可以搜索许多不同类型的东西。所有（目前）都需要为每种类型的搜索提供不同的输入字段。例如，可能会搜索学校或学区名称、class 名称、工作人员电子邮件地址等。我有 9 个不同的 'type' 搜索，每个搜索页面上都有自己的输入字段.我已经连接了其中一个（用户名和 UID 搜索），但我想知道将这些全部放入一个输入字段（因此是一个单独的搜索）在设计（用户友好）和性能方面是否有意义
这些不同的类型当然是一些不同的表，所以它要为每个类型查询很多次不同的时间，就为了一次搜索。
有什么想法吗？还是我应该保持原样？我可以添加一个下拉菜单来选择不同的 'type' 搜索，但这看起来同样混乱。当我不在主搜索页面（也恰好是主页）时，我已经为我的导航栏做了这个
我的项目是用金字塔框架Python编写的。
我可以看到它被发布到 UX SE（ux.stackexchange.com 我想？）网站，或者他们可能已经有一个问题涉及这样的事情。但就我个人而言，我可能倾向于使用下拉菜单 select 或使用不同的类型，或者保持单独的搜索不变。而且我认为我会更倾向于下拉框 - 对于搜索界面来说，这对我来说似乎不合理。
我想一个问题是 - 是否可以期望从同一搜索中的多个表中获得结果？如果是这种情况，我可以看到实施您的统一搜索想法，即使这意味着查询多个表。或者某种附加界面，您可以在其中 select 您想要查询的表。
如果应用程序发生变化，您的搜索界面会发生什么变化？这是一个非常重要的方面。您是否添加其他搜索类型？
搜索 returns 匹配查询字符串。结果集可以包含来自不同类型的不同实体。然后您的 search/resultset 界面可以应用基于实体类型或实体方面的过滤（示例：Ebay、Amazon）
从 Solr/elasticsearch 和附加项目中学习。分面搜索是用户现在习惯的。与编写跨多个表的复杂查询相比，分离数据存储 (RDBMS) 和全文搜索引擎的概念更加强大和可扩展。任何较大的互联网公司（Ebay、Facebook、Amazon、Instagram）都可以讲述有关使用这些模式的故事。将存储与搜索分开可提供可扩展性和灵活性。
与其编写 query/search 代码，不如学习如何从任何数据存储中为这些搜索引擎提供数据。我保证，这会更强大、更有趣。