MS Access前端：有哪些风险？

Question

我正在考虑为Oracle数据库构建MS Access前端。

我不是开发人员（我是一名公共工作人员），但我确实了解MS Access和Oracle。用户数量为5，可能增长到10-20。前端主要是报告，数据输入的奇数形式。安全不是主要问题;这是由数据库处理的，信息不敏感。

我知道MS Access项目通常最终会成为灾难性的怪物。据我所知，MS Access并不是一个企业系统。

然而我正在考虑它，因为，我没有任何其他选择。我不在I.T.和我的I.T.部门根本没有资源来帮助。在我的组织中，一个适当的，企业的，开箱即用的系统需要5到10年的时间。我不能等那么久。相反，我有MS Access可以使用。

我希望如果我坚持一些关键原则，那么前端不会成为一个脆弱的，灾难性的怪物，而是一个可持续和强大的系统。

我希望：

• 尽可能简单地保持它。如果功能不是绝对必要的，那么不要实现它。迫使利益相关者为他们的要求辩护。
• 仅将其视为原型，而不是正式的企业系统。让所有利益相关者庄严宣誓最终将其迁移到适当的企业系统。
• 配置，不要自定义。仅定制（VBA）作为绝对的最后手段。即便如此，在诉诸定制之前，请考虑不要做事。我这样说，因为我是办公室里唯一一个知道如何编剧的人，而我甚至都不擅长这个。
• 定期举行'消防演习'。如果它破裂了，我不在帮忙，会发生什么？定期举办培训/知识分享会，向同事讲授该系统。
• 倾向于系统，好像我正在照看花园。保持领先地位。通过简化，提高效率和删除不必要的功能来不断改进它。

尽管如此，即使我设法做这些事情，我猜测在MS Access中制作企业系统仍然存在问题。

企业MS Access前端有哪些风险和固有问题？

Answer 1

首先，你应该给自己信任！你肯定听起来没有经验;恰恰相反。您构建和维护系统的方法听起来很棒。关于你的限制，听起来你需要一个报告工具，听起来像Access是你唯一的选择。我知道这里有一条评论暗示Oracle Apex，但我认为这不是你的选择。使用Oracle的本机访问方法的产品肯定会比Access更好地执行，但这并不意味着你已经走到了死胡同。如果你理解它的局限性，那么Access是一个强大的工具（而且，我并不仅仅意味着2GB的文件大小限制;我怀疑你会遇到这种情况）。以下是我可以提供的一些建议，希望这听起来并不陌生：

1. 如果您能够将SQL编写为Oracle内的存储过程或视图，那么就这样做。
2. 不要链接到Oracle中的表，这将非常缓慢。
3. 不要使用ADO将数据从Oracle传输到Access，这也会很慢，因为它需要逐行处理。
4. 使用SQL传递查询连接到Oracle并执行存储过程/ views / SQL。这将是您最快的选择，因为Access只会将您的查询发送到服务器执行;它本身没有做任何事情来运行它（或估计如何运行它）。
5. 尝试在Oracle中执行所有逻辑。这意味着，如果您没有能力编写存储过程，并且需要创建临时表，那么请在oracle会话中或在通过SQL传递查询执行的SQL脚本内部执行此操作。
6. 如果您需要将数据传输到Access，请尝试限制它。您可能没有创建200页的报告，因此不要返回您不需要访问的数据;利用服务器的处理能力为您带来优势。
7. 假设您已完成所有这些操作，现在可以分发Access文件了。不要将数据库放在网络驱动器上并与用户共享。为每个用户提供自己的副本。现在，这个话题本身就是一个很长的讨论，因为像版本控制这样的东西会发挥作用，但我不会在这里讨论。如果用户每次需要使用它时都可以访问网站并下载干净的Access文件，那么就这样做。如果没有，并且它们将始终启动其本地副本，则需要在Access中实现任何本地数据的一些清理例程，然后启用紧凑的关闭设置，以消除可能影响性能的混乱。
8. 如果您对Oracle的查询效果不佳，并且您的报告最终变慢，请不要害怕寻求帮助。 DBA不会喜欢您所做的任何会影响其数据库性能的事情，因此请使用它们来帮助您调优SQL。