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并执行存储过程/视图/ SQL。这将是您最快的选择，因为Access只会将您的查询发送到服务器执行;它本身并没有执行任何操作（或估计如何运行它）。
5. 尝试在Oracle内部执行所有的逻辑。这意味着，如果您没有编写存储过程的能力，并且说您需要创建临时表，那么在Oracle会话中执行该操作，或者在通过SQL传递查询执行的SQL脚本中执行该操作。
6. 如果您需要需要将数据传输到Access，请尝试限制它。您可能不会创建200页的报告，因此不要返回您不需要访问的数据;充分利用服务器的处理能力。
7. 我们假设你完成了所有这些工作，现在准备分发Access文件。不要将数据库放在网络驱动器上并与用户共享。给每个用户自己的副本。现在，这个话题本身就是一个长时间的讨论，因为版本控制这样的东西会发挥作用，但我不会在这里进行讨论。如果用户每次需要使用它时都可以访问网站并下载干净的Access文件，那么请执行此操作。如果不是，并且他们将始终启动本地副本，则需要在Access中实施一些本地数据的清理例程，然后启用紧凑关闭设置，以消除可能影响性能的混乱。
8. 如果您对Oracle的疑问表现不佳，并且您的报告速度变慢，请不要害怕伸出援手。 DBA不会喜欢你会做任何会影响其数据库性能的事情，因此请利用它们来调整SQL。