我目前正在管理/开发Access 2010前端/ SQL后端数据库。我们正在尝试改进前端性能，并且已经提出的一个解决方案是将运行前端的大量VBA推送到服务器上的存储过程中。我对VBA非常熟练，但对SQL和网络架构却很陌生。我在谷歌上发现的一切都是关于拆分数据库的信息，这已经完成，而不是有关运行存储过程与运行VBA导致的网络负载的信息。
当前设置与将此操作推送到存储过程之间的网络流量有何不同？
作为一个具体示例，如果我在当前设置中填充表单，则会运行一些查询以向表单上的不同元素提供数据。使用当前的体系结构，Access是否从后端检索查询的表，在客户端查询它们然后填充数据？如果在表单加载时执行SP，并且仅传输显示表单所需的数据，那么网络流量会有何不同？
最终目标是减少Access和SQL之间的混乱，我主要试图弄清楚究竟发生了什么。
答案 0 :(得分：2)
作为一般规则，如果您启动一个带有where子句的表单以将表单限制为一个记录，那么使用绑定表单或采用存储过程不会导致网络流量的任何差异或减少。 / p>
基于表的任何本地访问查询都只会请求一条记录。在这个方面，没有“局部”处理概念，带有链表。请注意“table”或“singular”这个词。
Access不会也不会下拉整个表，除非你有这样的表格和quires，没有任何“where”子句来限制所提取的数据。
换句话说，如果您的设计形式设计不佳，请将该设计转储并更改为现在仅下拉一条记录的内容，当然，设置将导致网络流量减少。
但是，上述减少不是采用存储过程，而是采用一种设计，即将请求的记录限制在表单中。
所以做一些不好的事情然后改进这个过程并不是采用存储过程的理由。
因此，在将记录拉入表单的情况下，使用存储过程不会提高性能。更糟糕的是将表单绑定到存储过程会产生一种只有READY ONLY的形式！
因此，在谈论根据响应时间或性能将记录加载到表单时，存储过程无需提高性能或减少网络流量。
如果必须进行大量的记录集处理，那么当然采用存储过程可以节省网络性能。因此，代替一些VBA代码来处理100,000个工资单reocrds，那么移动这样的代码服务器端将有所帮助。但是，处理100,000个工资单记录并非常见任务，并且在大多数情况下无论如何都不是用户界面问题。换句话说，您没有缓慢的加载形式或加载此类表单的响应时间较慢。换句话说，等待表单加载的用户不会进行这种类型的处理。
SQL服务器确实是一个高性能系统，也是一个可以扩展到许多用户的系统。
如果您使用c ++或VB编写应用程序，或者使用ms-access编写应用程序，则在GENERAL中，所有这些工具的性能都是相同的。
换句话说...... sql server相当不错，是IT行业中使用的标准系统。
但是，如果您不付出努力，sql server将无法解决您的性能问题。并且，事实证明，同样努力的MOST也使您的非SQL服务器访问应用程序运行得更好。
事实上，我们看到许多帖子提到移动后端数据 到SQL服务器实际上减慢了事情。 （事实上，在一台机器上，Access JET（现在称为ACE）实际上是更快的SQL服务器（所以当同一台机器上的单个用户 - 在大多数情况下，Access在同一台机器上的速度比SQL服务器快）。
一些事情：
拥有75k记录的表格非常小。假设您有12个用户。只有100％的文件库系统（jet），而且没有sql server，那么该系统的性能应该真的让人尖叫。
我有一些应用程序有50个或60个高度相关的表。在网络上有5到10个用户，响应时间是即时的。我认为任何表单加载都不会超过一秒钟。这60多个表中的许多表都是高度相关的，并且在50到75k的记录范围内。
因此，对于我的5位用户，我认为没有理由无法在75,000记录范围内使用如此小的表扩展到15位用户。这是没有SQL服务器的。
如果应用程序没有执行只有75k记录的小型表，那么升级到sql server将无法解决性能问题。实际上，在sql server新闻组中，您会看到那些发现升级到sql的人每周发布的帖子实际上会减慢速度。
我甚至看起来有些非常酷的数字显示一些查询在JET和sql server的网络使用方面实际上更有效。
我的观点是，技术不会解决性能问题。但是，谨慎使用有限带宽资源的良好设计是关键。因此，如果应用程序没有以良好的性能编写，那么你就会陷入糟糕的设计！
我的意思是，当使用JET文件共享时，您从75k记录表中获取发票，只有一条记录通过网络传输到文件共享（并且，sql server也只传输一条记录）。所以，在这一点上，你 通过升级到SQL Server，确实不会注意到任何性能差异。这里没有魔力。采用SQL存储过程甚至会浪费大量时间！
采用存储过程取代上述也不会让你获得表现！
Sql server是一个强大且可扩展性更强的产品，然后就是JET。并且，安全性，备份和主机等其他原因使得sql server成为一个不错的选择。但是，sql server不能解决处理像75k记录这样的小表的性能问题
当然，在努力利用sql server时，可以实现性能的显着提升。
我将提供一些提示......当使用ms-access作为文件共享（没有服务器），甚至odbc到sql server时，这些都适用：
**在加载表单之前询问用户他们需要什么！
以上是如此简单，但我常常忽略上述概念。例如，当您走到即时取款机时，它是否下载了每个帐号，然后问您想要做什么？
在访问中，打开附在桌子上的表格是完全愚蠢的，没有先询问用户他们想要什么！因此，如果是客户发票，请获取发票编号，然后使用ONE记录加载表单。怎么一个记录慢？完成编辑记录并关闭表单后，您将回到提示状态，准备与下一位客户进行战斗。
你可以阅读这个＆＃34;流动＆＃34;良好的用户界面在这里工作（这适用于JET和SQL Server应用程序）：
http://www.kallal.ca/Search/index.html
我唯一的观点是将表单限制为只有用户需要的ONE记录。通过使用存储过程来完成此任务，您不需要也不会获益。我总是感到沮丧的是，开发人员经常建立一个漂亮的表单，将它附加到一个大表，然后打开它并抛出这个表格附加到一个巨大的表，然后告诉用户去拥有它并享受乐趣。我们对那些可怜的用户不抱任何顾虑吗？通常，用户甚至不知道如何搜索某些东西！
如此迅速，并要求用户在可用性方面也取得了巨大的飞跃。而且，最大的好处是减少了网络流量！天哪更好更快，网络流量更少！我们还想要什么！
**使用需要多个链接表的quires注意
JET很难将odbc表连接在一起。 Access数据引擎（jet / Ace）通常做得很好，但这种连接通常很慢。但是，大多数编辑数据的表单都不基于多表查询。 （因此，存储过程不会加速表单加载以进行数据编辑）。
这种多连接（对于表单和报表）的简单解决方案是将sql server端构建为视图，然后链接到该视图。
这种视图方法比存储过程少得多，导致服务器端出现连接。当您采用存储过程时，结果视图是可更新的，而不是READ ONLY。此类视图的性能将再次与此上下文中的存储过程相同。
因此，一旦获益，采用存储过程无济于事，而且开发人员的成本比使用视图更昂贵。实际上，这只是让人们建议你拿出账单并利用开发人员的时间创建一些除了更多的计费时间之外什么都不会产生任何结果的东西。
我不认为它需要指出如果有问题的查询已经运行良好，那么上面的内容可以忽略，但请记住，基于sql server链接的多个表的本地查询往往运行缓慢。所以，请注意以上几点。
此视图技巧也适用于组合框。
因此，可以继续将绑定表单用于链接表，但只需将表单限制为您需要的ONE RECORD。
您可以安全地打开一张发票表单等，但只需确保打开此类表单（openForm），方法是通过＆＃34; where＆＃34;条款。这里不需要查看或存储过程。
绑定表单的工作方式少于未绑定的表单，并且在正确完成时性能通常也同样好。
避免大量加载组合框。组合框适用于约100个条目。之后，你正在折磨用户（他们要通过100个条目查看）。因此，将组合框等内容保持在最小尺寸。这更快，更重要的是它对您的用户更友好。
毕竟，在一天结束时，我们真正想要的是善待用户。似乎很好地对待用户，减少带宽（数据量）是相辅相成的。
因此，更好的应用程序可以很好地处理用户并且运行得更快！ （这是个好消息！）
因此，＃1提示是减少您传输到表单中的数据。
在绝大多数情况下不需要使用存储过程，并且不再减少带宽要求，然后采用where子句和视图。