设计基于服务器的访问数据库时的标准步骤是什么？答案

【问题标题】：What Are the Standard Steps when Designing a Server-Based Access Database?设计基于服务器的访问数据库时的标准步骤是什么？
【发布时间】：2014-09-12 15:07:52
【问题描述】：

我知道这是一个宽泛的问题，我试图避免提出一个有无限答案的问题，但是，在为我缺少的服务器设计 Access 数据库时，必须有一套标准的标准规则.

我问的原因是因为我目前有一个数据库，它作为桌面应用程序启动，我现在想将它移动到服务器上。但是，我基本上是在运行中创建了这个数据库，并且目前正在讨论废弃数据库的前端，因为我觉得我错过了开发端的关键步骤。对于构建基于服务器的数据库的基本操作方法，我真的需要专家的意见。

感谢您的时间和考虑。

编辑这是一个很好的指南链接，它列出了制作基于服务器的 Access 数据库时的“最佳实践”。

http://www.opengatesw.net/ms-access-tutorials/Access-Articles/MSAccess-Deployment-Best-Practices.htm

希望其他人发现它和我一样有用。

【问题讨论】：

我必须提供的第一个建议是不要使用 ms-access，它根本无法扩展到大型请求，并且不能像服务器通常那样一次处理多个请求。第二个建议是开始将您需要存储的内容映射到一个大列表中，然后开始规范化您的数据并在需要的地方添加键。当您完成对列表的规范化时，您将拥有一个很好的表和键集合，并且应该处于一个安全的位置，可以开始为表等分配名称。
很好的建议，我真的很感激。除了桌面数据库之外，我一直在讨论是否将 ms-access 用于服务器数据库，现在我知道我应该放弃 ms-access。我将对在设计基于服务器的数据库时使用什么进行更多研究。我完全同意，我完全错过了绘制我的数据！再次感谢您的意见！
@scragar 如果“不 ... 使用 ms-access”是指“不要使用 Access 数据库文件作为后端”，那么您可能有一个观点，具体取决于数字并发用户的数量，数据库文件的大小等。但是，您声称 Access 数据库引擎“无法一次处理多个请求”根本不正确。此外，即使后端数据库是 SQL Server（或者可能是其他一些客户端-服务器数据库产品），Access 也可用于构建前端应用程序。
@GordThompson 理论上它最多支持 255 个连接，但实际上，如果他们正在执行写入，它将开始阻塞超过 5 或 10 个连接（显然取决于他们正在做的事情的规模）。如果你想要一个服务器来做一些事情，你是否计划在未来的某个时候让十几个人使用它（或者至少会喜欢这个选项）。
我也许可以用这个躲过一劫，因为我相信一次只有四个人访问这个数据库。这是一个相对较小的数据库。我感谢你们所有人对此的想法，我肯定会做笔记。我知道这与我的问题无关，但是，鉴于到目前为止的输入，我应该使用什么来构建一个基于服务器的小型数据库（即：mySQL、VisualStudio）？

标签： ms-access vba access-data-project

【解决方案1】：

与使用 Access + SQL 服务器相比，现有 Access 应用程序中的优秀设计没有任何真正的变化。

换句话说，您可以使用现有的应用程序并将数据表移动到 SQL 服务器，然后继续使用现有的 Access 应用程序作为前端。

这里没有真正的建议适用于“仅”没有 SQL Server 的 Access 以及使用 Access + SQL Server 的建议。换句话说，您实际上不必更改构建 Access 应用程序的方式以使用 SQL Server。

在仅使用 Access 的应用程序中扩展和运行良好的良好设计在使用 Access 作为前端并使用 SQL 服务器作为后端时也往往运行良好。

基本提示是：

打开表单时，请在启动表单之前询问用户。启动一个从服务器拖动大量记录然后询问用户什么帐户# 或需要什么的表单是没有意义的。因此提示用户进行某种类型的搜索。说一个这样的屏幕：

即使使用一百万行访问 SQL 服务器，上述内容也是即时的。以上使用来自 Access 的 100% 链接表，这里没有任何特殊技巧 - 只需将一个简单的 SQL 语句推入子表单。所以这是一个链接到 SQL 服务器的视图。

然后，当用户单击一行时，您只需使用 where 子句（“ID =” & me!id）启动表单。

这个“where”子句即使在 SQL 服务器上也适用于 Access 绑定表单和链接表。

将视图用于报告中的复杂查询（具有客户端过滤器请求）。

您可以对某些报告采用传递查询以获得更高的性能，但在大多数情况下，创建视图 SQL 端并从 Access 链接到它们效果很好，而且工作量最少。

因此，使用 Access 和 SQL Server 开发软件的方式没有真正的“变化”。唯一的问题是始终记住，在您确定用户想要编辑的内容之前，您不希望将记录加载到表单中。这种方法不仅适用于使用 Access + SQL Server 的情况，即使只是基于文件的 Access 应用程序，您也不需要也不希望将不必要的记录拉入表单以减少网络负载。

附加到 OpenForm 命令的“简单” where 子句在绝大多数情况下就足够了。

因此，开发一个好的仅 Access 应用程序或 Access + SQL 服务器应用程序的方式没有“真正的”变化。

【讨论】：

我唯一的困难是我开发的数据库由 3 个较小的数据库及其管理概述组成。例如，我有一个管理工具和设备的数据库和另一个处理机车车辆的数据库。另外，我还有另外两个数据库，第一个管理对上述数据库的维护，另一个管理上述数据库的订单请求。在大多数情况下，它们相互通信（即：可以在带有子表单的表单上看到布拉德钉枪上的订单和维护），所有这些都通过 NavForm 链接。我还能把这些带到服务器上吗？
我在您的 cmets 中看不到任何真正改变此类数据库设置如何工作的东西。因此，您需要拆分数据库。所以用户界面部分不会有数据表，只有链接。并且链接到不同的数据库并没有太大变化，听起来你一直在使用 Access 的链接功能。因此，如果此设置导致 3 个不同的数据库，那么任何前端都可以链接到此类数据库（无论是 Access 后端，还是 SQL 后端）。
我会记住这一点。我买了一本书，详细介绍了将桌面数据库转换为基于服务器的数据库时要采取的具体步骤。现在，我只是设置错误陷阱并找到一种方法来防止人们输入重复/不正确的记录。编码，编码，编码。
优秀。作为后续 99% 的现有代码应该可以正常工作。表现在是 SQL 服务器这一事实几乎没有变化。因此，所需的任何“编码”通常不会改变，因为您的表现在驻留在 SQL 服务器上，而不是 Access 表。通常不必更改您编写的表单和 VBA 代码，因为该表现在位于 SQL 服务器上，而不是 Access 表。祝你好运！
这绝对是一种解脱！我和我的朋友下周将坐下来把这个数据库放到服务器上（或者至少准备好在服务器上运行）然后从那里开始。再次感谢您的建议！