哪个更快？查询本地 table，或组合框控件中的编程值列表
Which is faster? Query to a local table, or a programmed value list in a combobox control
我在表单上有一系列组合框 - 过去我通过使用对 sql 服务器的传递查询将它们连接到数据列表，虽然这在大多数情况下，我的许多用户一直在使用 VPN 访问数据库，并且填充它们的响应似乎很慢。
我开始对系统进行编程，以通过表单加载时的传递查询填充本地 table - 然后，使用本地查询以正确的顺序显示结果。一旦他们 select 第一个组合框，第二个组合框从那里过滤到第三个和第四个（在某些情况下我也有超过 4 个），
所有这些都是为了让我不必在每次更改 selection 时都连接到服务器。但是，我认为拥有一个硬编码的值列表对于不改变的列表来说可能在性能上更快——比如 selection hiearchy 中的最高级别（想想 3 或 4 个组合框相互影响并过滤下一个结果）。
有谁知道在组合框中使用硬编码值列表是否比在 MS Access 中对本地 table 进行本地查询具有性能提升？如果有帮助，我正在使用 MS Access 2016。
与其使用从 SQL 服务器链接的 table，不如考虑对很少更改的任何值（例如国家/地区）使用本地 table。
将 table 的主节点保存在 SQL 服务器中。当需要更改时，更新 master table，然后在部署之前导入到您的前端。
通过这种方式，您将获得比非本地 tables 更快的速度，并且能够在查询等中使用这些 tables。由于相同的数据保存在 Access 前端和 SQL 服务器后端，您仍然可以使用相同的数据在 SQL 服务器中创建视图。
此致，
好的，有几点：您不想对 listbox/combo 框使用传递查询。从不!!!!
为什么？ Access 客户端无法筛选 PT 查询。这在这里似乎是矛盾的。
首先，让我们明确一点：提取数据的最快方法是 PT 查询 - 毫无疑问。
但是，我们假设组合框很大——比如 3000 行。
并且还假设组合框已绑定（这意味着它将值保存到表单的绑定记录集中。
嗯，记住上面的规则！！！ - 访问客户端永远无法过滤 PT 查询。
那么，如果您有报告说您 运行？如果您的 PT 查询未预先过滤（条件存在于 PT 查询中 - 甚至是存储过程），则将 where 子句添加到表单（或报告），或者在这种情况下组合框将不起作用 - FULL数据集已 return 编辑，无法过滤。
因此，如果您有一个包含 500,000 行的 PT 查询，并且您这样做：
docmd.OpenReport "rtpInvoice", acViewPreview,,"InvoiceNumber = 1234"
以上将拉取 500,000 行。
但是，如果您使用 jane linked table 或 best link 视图，并且它也有 500,000 行？嗯，只有 1 条记录通过网络管道！
那么，如果该组合框绑定到 5000 行，并且发生到 NEXT 记录的简单导航？好吧，组合框当然会有一个值——绑定表单的基础记录集。但是，它无法过滤 + 显示组合框的 ONE 值（大多数组合框是多列的 - 第一列 = PK，第二列 = 某种描述。
因此，access 实际上非常智能，它会尝试仅从驱动组合框的 5000 行中提取一个值。但规则的例外当然是 PT 查询！
再次说明：Access 客户端无法过滤 PT 查询。
所以，如果组合框有一个大数据集并且还由 PT 查询提供，那么事情 运行 就像狗一样慢。我有一个系统，其中 PT 查询 returning 大约 100,000 行。只是简单地导航到下一条记录就慢得像条狗。
用 linked 视图替换 PT 查询使表单几乎可以即时工作。这是因为在 100,000 行中，Access 只能拉出一行用于显示组合框和第二列。
那么，虽然 PT 查询是提取数据的最快方式？是的，100% 正确，但您只想在需要该 PT 查询的所有记录时使用该速度优势。如果您要在 PT 查询之后或反对 PT 查询之后进行过滤（例如针对绑定的组合框所做的），那么将对驱动该组合框的所有记录进行全面扫描。
最佳方法？转储组合框的 PT 查询，并用 linked 视图替换它们。您甚至可以在视图中指定排序（是的，它确实会排在前 100%）。所以只将视图名称放在组合框中 - 不要启动查询生成器。
而且，您甚至可以使用直接 link 到 linked table。同样，Access 客户端可以为组合框过滤该数据集。
因此，开发人员无需浪费所有时间为组合框构建 PT 查询，也无需（也没有速度优势）尝试使用代码来加载和填充组合框。但是，如果 PT 查询要 return 超过大约 30 行，那么你想转储 PT 查询并使用 linked table，或者更好的是 link编辑视图。
我不会胡思乱想将 table 从服务器拉到本地 - 你可以这样做，但那只是额外的代码，额外的痛苦，而且它确实给你带来了很少的好处。通常它会使事情变得更糟。为什么要为组合框拉出整整 table 行，当刚启动表单时，access 足够智能，可以只拉出显示组合框所需的一行。在您单击组合进行选择之前，它不会提取数据。
如果您的 PT 查询是说超过 50 或 100 行来填充组合框，并且该组合框是绑定的组合框？然后你必须转储 PT 查询，并使用 linked table/view - 你会获得更好的性能。
我在表单上有一系列组合框 - 过去我通过使用对 sql 服务器的传递查询将它们连接到数据列表，虽然这在大多数情况下，我的许多用户一直在使用 VPN 访问数据库，并且填充它们的响应似乎很慢。
我开始对系统进行编程，以通过表单加载时的传递查询填充本地 table - 然后，使用本地查询以正确的顺序显示结果。一旦他们 select 第一个组合框，第二个组合框从那里过滤到第三个和第四个（在某些情况下我也有超过 4 个），
所有这些都是为了让我不必在每次更改 selection 时都连接到服务器。但是，我认为拥有一个硬编码的值列表对于不改变的列表来说可能在性能上更快——比如 selection hiearchy 中的最高级别（想想 3 或 4 个组合框相互影响并过滤下一个结果）。
有谁知道在组合框中使用硬编码值列表是否比在 MS Access 中对本地 table 进行本地查询具有性能提升？如果有帮助，我正在使用 MS Access 2016。
与其使用从 SQL 服务器链接的 table，不如考虑对很少更改的任何值（例如国家/地区）使用本地 table。
将 table 的主节点保存在 SQL 服务器中。当需要更改时，更新 master table，然后在部署之前导入到您的前端。
通过这种方式，您将获得比非本地 tables 更快的速度，并且能够在查询等中使用这些 tables。由于相同的数据保存在 Access 前端和 SQL 服务器后端，您仍然可以使用相同的数据在 SQL 服务器中创建视图。
此致，
好的，有几点：您不想对 listbox/combo 框使用传递查询。从不!!!!
为什么？ Access 客户端无法筛选 PT 查询。这在这里似乎是矛盾的。
首先，让我们明确一点：提取数据的最快方法是 PT 查询 - 毫无疑问。
但是，我们假设组合框很大——比如 3000 行。
并且还假设组合框已绑定（这意味着它将值保存到表单的绑定记录集中。
嗯，记住上面的规则！！！ - 访问客户端永远无法过滤 PT 查询。
那么，如果您有报告说您 运行？如果您的 PT 查询未预先过滤（条件存在于 PT 查询中 - 甚至是存储过程），则将 where 子句添加到表单（或报告），或者在这种情况下组合框将不起作用 - FULL数据集已 return 编辑，无法过滤。
因此，如果您有一个包含 500,000 行的 PT 查询，并且您这样做：
docmd.OpenReport "rtpInvoice", acViewPreview,,"InvoiceNumber = 1234"
以上将拉取 500,000 行。
但是，如果您使用 jane linked table 或 best link 视图，并且它也有 500,000 行？嗯，只有 1 条记录通过网络管道！
那么，如果该组合框绑定到 5000 行，并且发生到 NEXT 记录的简单导航？好吧，组合框当然会有一个值——绑定表单的基础记录集。但是，它无法过滤 + 显示组合框的 ONE 值（大多数组合框是多列的 - 第一列 = PK，第二列 = 某种描述。
因此，access 实际上非常智能，它会尝试仅从驱动组合框的 5000 行中提取一个值。但规则的例外当然是 PT 查询！
再次说明：Access 客户端无法过滤 PT 查询。
所以，如果组合框有一个大数据集并且还由 PT 查询提供，那么事情 运行 就像狗一样慢。我有一个系统，其中 PT 查询 returning 大约 100,000 行。只是简单地导航到下一条记录就慢得像条狗。
用 linked 视图替换 PT 查询使表单几乎可以即时工作。这是因为在 100,000 行中，Access 只能拉出一行用于显示组合框和第二列。
那么，虽然 PT 查询是提取数据的最快方式？是的，100% 正确，但您只想在需要该 PT 查询的所有记录时使用该速度优势。如果您要在 PT 查询之后或反对 PT 查询之后进行过滤（例如针对绑定的组合框所做的），那么将对驱动该组合框的所有记录进行全面扫描。
最佳方法？转储组合框的 PT 查询，并用 linked 视图替换它们。您甚至可以在视图中指定排序（是的，它确实会排在前 100%）。所以只将视图名称放在组合框中 - 不要启动查询生成器。
而且，您甚至可以使用直接 link 到 linked table。同样，Access 客户端可以为组合框过滤该数据集。
因此，开发人员无需浪费所有时间为组合框构建 PT 查询，也无需（也没有速度优势）尝试使用代码来加载和填充组合框。但是，如果 PT 查询要 return 超过大约 30 行，那么你想转储 PT 查询并使用 linked table，或者更好的是 link编辑视图。
我不会胡思乱想将 table 从服务器拉到本地 - 你可以这样做，但那只是额外的代码，额外的痛苦，而且它确实给你带来了很少的好处。通常它会使事情变得更糟。为什么要为组合框拉出整整 table 行，当刚启动表单时，access 足够智能，可以只拉出显示组合框所需的一行。在您单击组合进行选择之前，它不会提取数据。
如果您的 PT 查询是说超过 50 或 100 行来填充组合框，并且该组合框是绑定的组合框？然后你必须转储 PT 查询，并使用 linked table/view - 你会获得更好的性能。