嗯，使用 Azure 比运行连接到本地 SQL 服务器实例的 Access 慢的原因是，慢就是慢！
我的意思是，如果你要旅行 30 英里，你可以选择步行或开车。
所以这是你需要知道的问题：
为什么走路比开车慢？
答案：因为您的行驶速度较慢！
那么，为什么使用 Azure 会比使用在本地计算机或本地网络上运行的 SQL Server 实例更慢？
回答：
因为到 Azure 的连接速度大约慢了 100 倍！
您不考虑连接速度差异的想法是这里的问题。如果读者认为这样的设置（PC 上的前端访问 SQL 服务器的 Azure 实例）不是一个可行的设置，这对读者来说是一种伤害。
所以这里的第一个问题是记下您与后端数据库的连接速度。
典型的办公室局域网速度为 100 兆比特，或者如今大多数为 1 吉格——即使您在百思买购买的 el-cheapo 路由器现在的额定速度为 1 吉格（1000 兆比特）。
但是，您的典型高速互联网的额定速度约为 5 或 10 mb。所以这慢了 100 倍。 （实际上 1000/5 = 慢了 200 倍！！！）。
这意味着如果现在使用 Access 和 SQL Server 在您的办公网络上花费 3 秒时间？然后是一个 WAN（通过互联网），然后你需要通过改变连接速度来倍增时间（这很简单——但它似乎完全逃脱了！）。所以，如果你幸运的话，你的互联网速度可能会达到 5 mbs。这意味着你走了
1000 / 5 = 200
您现在取 200 和现有延迟的倍数，例如 3 秒，得到 600 秒（如果您想知道，那就是 10 分钟！）。所以你从 3 秒缩短到 10 分钟！
这种速度上的比较就像走进一家体育用品店购买橡皮艇横渡大西洋一样。因此，不考虑互联网速度的变化并想知道为什么速度很慢是这里的问题。
您当然可以使用 Access to Azure，但您必须了解两个简单的概念。
- 使用比 LAN 慢 50 到 200 倍的连接进行连接和测试是运行速度会慢 50 到 200 倍的测试！与 WAN 相比，没有提及和考虑 LAN 连接速度的巨大差异是一个简单的问题。
- 打开绑定到大型数据表的表单会出现性能问题。
我正坐在公交车站与一位 90 岁的老奶奶交谈。我问了她以下问题：
你用过即时取款机吗？
她说，为什么是的，我一直在使用它们。
然后我在这里问你，你不觉得让柜员机在你等待的时候下载所有的人的账户，然后问你你的账号是不是很糟糕？
老太太说，当然，那是愚蠢的。我输入我的帐户密码，机器只下载我的帐户信息——这既实用又明显。
换句话说，那位老太太意识到，在用户输入或执行任何操作之前下载大量数据是浪费带宽。
因此，您永远不想启动绑定到表的表单，然后询问用户要处理的记录。为什么要让 Access 将大量记录下载到表单中，然后询问用户或允许用户导航到所需的记录？
即使使用谷歌，它也不会将整个互联网下载到您的网络浏览器页面中，然后您可以使用 ctrl+f 搜索该网页的内容。
同样的概念也适用于 Access 应用程序。询问要处理什么，然后使用“where”子句启动绑定到表的表单的设计将解决此问题。
因此，如果您有一个显示客户发票的表单（甚至是子表单），您将首先询问发票编号，然后使用将表单限制为一张发票的 where 子句简单地启动该表单！
请记住，您仍然可以使用绑定到包含 100 万行的表的发票表单，并且只有一条记录将被拉下网络连接 *如果使用where 子句.
因此，典型的互联网连接具有足够的速度来运行浏览器，并且还具有足够的带宽速度来下载一些记录。 Access 经常因性能不佳而受到批评，但这只是因为 Access 开发人员忽略了一个明显的建议，即将大量不需要的内容下载到表单中会运行缓慢。
因此，基于 Web 的应用程序，甚至是用 vb.net 编写的桌面应用程序在云端运行的 SQL Azure 上运行良好，但互联网连接速度要慢得多，因为这些应用程序不会启动绑定到大型数据集的表单，而无需首先简单地允许用户请求他们需要查看和查看的内容。
对于 Access 和使用 SharePoint？该设置可以非常快，实际上比 SQL Azure、MySQL 或任何传统数据库系统快得多，因为当您使用 SharePoint 表和 Access 时，Access 会自动同步本地数据的副本。此设置意味着您的应用程序将在没有任何 Internet 连接的情况下继续运行。一旦连接恢复，数据同步就可以恢复。
这意味着，如果您有一个包含 15,000 行的表并针对该数据运行报告，则该报告可以通过 SharePoint 后端立即运行和启动，因为数据的本地副本始终存在于前端！因此，此设置非常适合离线模式，或者在您的互联网连接较差且速度较慢的情况下，因为如上所述，您始终拥有数据的本地副本 - 只有在更改记录时才会发生同步，并且同步可以发生独立于访问。因此，您更改了一条记录，它开始与 SharePoint 同步。
但是，对于必须更新的较大数据集，SQL Server 要好得多，因为您可以在 10,000 行上执行 sql 更新，并且在使用 SQL Server 时需要发生零网络流量和数据传输来更新这 10,000 行（传递查询），并且在使用 SharePoint 时，这 10,000 行将通过网络传输，因为本地副本需要更新行。因此，对于必须更新大量行或执行大量行更新类型的数据处理的应用程序，不存在将 SharePoint 用于数据库后端的巨大优势。
所以这里的关键概念和要点：
您拥有的高速互联网连接通常比典型的廉价办公室（本地）网络慢 10-200 倍。因此，这意味着 2 秒的操作现在将花费 10-200 倍的时间。
需要优化 Access 应用程序以避免将太多记录加载到表单中。因此，构建搜索表单等。首先询问用户他们需要做什么是所有优秀开发人员（包括 Access 开发人员）的基本且简单的要求。
Access 和 SharePoint 可能是最佳选择，这样的设置允许应用程序在完全没有互联网连接的情况下运行。如果表大小低于 10,000 行，那么这种设置通常是理想的。但是，对于必须更新大量行的应用程序和数据处理繁重的应用程序，此设置很差，因为对任何行的更新都会导致数据同步通过网络发生。这种设置也是最便宜的，因为一个带有 SharePoint 支持 Access 的 Office 365 帐户每月只需 6 美元，而这个 6 美元的帐户最多允许 500 个免费用户，这 500 个用户甚至可以使用他们的 Gmail 或非 Microsoft 帐户对于这个设置。与通过 Internet 使用 SQL Server 相比，此类适合 SharePoint 表范围的访问应用程序往往需要更少的更改和优化。
使用 SQL Server，使用视图、通过严格的查询以及在某些情况下编写存储过程允许更新和代码在不使用任何带宽的情况下运行。因此，可以向更新 10,000 行数据的服务器发送一个更新查询——唯一的网络成本将是发送该 sql 语句的“微小”带宽量。
因此，虽然绑定表单可以与在云中运行的 SQL Azure 一起使用，但需要构建类似那些为 web 或 vb.net 做的软件，在其中他们首先询问用户要使用哪个帐户或客户，然后启动 UI 以显示给定的数据。
所以在访问中，您构建一个搜索表单，如下所示：
因此，归根结底，重要的是忽略此处暗示在云中访问 SQL 不可行的帖子。通过与 Azure 上运行的 SQL 服务器的典型 Internet 连接，采用适当设计的访问将非常有效。
事实上，我看到人们通过 56k 调制解调器使用 Access to SQL！
必须采用合理的设计，其中限制为给定任务提取的数据 - 这是所有开发人员的标志 - 唯一的问题是 Access 不强制执行此方法，而大多数其他开发人员工具不允许您这样做用大桌子上的绑定表格等东西吊死自己！并不是说 Access 很慢，而是当您做出糟糕的设计决策时，Access 会很慢。
访问 SharePoint 可能是真正的赢家 - 特别是对于带宽不足、带宽不稳定甚至连接断开时，如果您使用SQL 后端。这里有一个很大的警告，因为只有某些类型的应用程序才能很好地与 SharePoint 表配合使用。对我来说，解释这些应用程序为什么、如何以及何时更好，这不仅仅是一篇简单的文章，但需要注意的是，SharePoint 可以是令人难以置信的解决方案，但并非适用于所有应用程序，SQL Server 可以并且将会是更好的选择.这种 SharePoint“更好”的选择只能根据给定类型的相关应用程序的个案评估来确定。