MS Access作为企业软件？

我经常与用户讨论的事情是他们希望快速获得解决方案,这意味着他们有时会说"哎呀,我只是卷起袖子然后在Access中完成它 - 它安装在我的桌面上".

有时,我们很幸运,创建Access数据库的人将其后端转发到SQL Server,因此至少通常出现的mdb文件问题不是问题.

但是,我认为将Access前端部署到SQL Server数据库作为具有数千个用户和数十万行的企业解决方案仍然存在问题.

你对此有何看法？有哪些潜在的陷阱？

要么

这是一个完全可接受,稳定,可维护且强大的解决方案吗？

我已经很好地使用了这个场景.事实上,作为顾问/开发人员,Access前端SQL Server后端在过去10年中一直是我的面包和黄油工作的重要组成部分.这并不意味着我喜欢 Access ;-)

直到共同采用AJAX,这是一个非常合理的解决方案.还有大量的中小型应用程序放在Access中,完全愉快地运行定制的业务系统,我怀疑它将在未来10年或更长时间内消失 - 实际上Access/SQL可能会是21世纪的Cobol.如果您正在"绿色领域"网站上工作,那么现在几乎没有理由在从头开始构建时部署Access - 但如果您继承了现有应用程序,那么重写的成本可能不值得且难以通过用户.

Access确实具有一些仍然重要的优点 - 如果提议转换为Web应用程序,可能会出现问题

这很快.对于简单的CRUD工作,它的编写和部署速度与任何其他实际解决方案一样快.

鉴于系统,内置报告易于运行且功能非常强大.通常很容易为用户按需创建和部署新报告.

它与Office完美集成.当想要将Access应用程序移动到web应用程序时,这个往往是显示阻止."部门级"Access应用程序与Outlook,Word或Excel 紧密集成是非常常见的- 通常都是三者.这是处理现实情况时的主要问题.编码人员很容易低估这种系统在日常使用中的重要性,并且对用户施加甚至更小的额外麻烦通常会遇到很大阻力 - 通常足以完全破坏项目.

如果你在一个合理规模的部门工作 - 大约十几个人 - 那么办公室里有人会把自己看作是一个计算机向导,这是很常见的.如果处理不当,这些人可能是一个主要的痛苦,但同样可以是一个重要的资产.如果我有这样一个人,我会尽量让管理层给他们上的访问过程或两个,使他们能够编写简单的查询和报表,并为他们设立一个单独的应用程序访问它们自己的它具有对SQL数据库的适当(受限制)访问权限.然后,您可以信任此人为其同事处理简单报告等.这可能是一个真正的双赢 - 你会得到一个站在你身边的人,并会将你当作导师 - 在部门中为你做一个现成的倡导者 - 并且他们会保持咕噜咕噜的报告不受你的影响.他们获得了很多荣誉和工作满足感 - 甚至是潜在的职业道路.使用除Access之外的任何其他系统来做这种事情要困难得多,几乎不可能.

主要实际缺点

部署可能是一场噩梦.一般来说,如果你有一个非常严格的环境 - 一个小公司,一个部门,基于Citrix或分布在一个IT部门,密切控制它的PC,那么你就没事了.作为跨多家公司的商业应用程序进行部署 - 只有在您可以收取大量维护费用的情况下才能进行部署.

代码无法扩展.访问VBA代码,即使是由专业人士撰写也有很强的腐蚀倾向于腐败的spagetti.最终使用易于维护的Access应用程序是很常见的,但随着依赖性的增加而逐渐变得不可维护.

因此,我认为Access仍然占有一席之地,并且在许多现实世界中它的使用是可以防御的,但如果情况允许,越来越多的选择更现代的解决方案.

我们已经建立了这样一个解决方案(Access前端,SQL后端),现在有80个用户,在不同国家之间复制了数百万行,每个月有超过10万个更新.它工作正常.我认为Access的主要错误是将其视为业余爱好者开发应用程序的工具.它可以这样工作,但请记住,业余开发将为您提供业余应用程序,而专业开发将为您提供专业的结果.

快速列出其优点,问题和限制:

由于msAccess运行时,它对最终用户是免费的

它适用于免费的SQLServer Express,而不是那么昂贵的SQL Server Enterprise.

这很快,特别是在处理表格时

它可以与其他Office应用程序轻松通信,这些应用程序仍然是企业标准

您可以将其界面管理得非常接近Office标准,使用它可以非常直观,让人们感到高兴(我在博客上谈了一点,需要更新!)

在大规模上,您必须考虑将其分发给用户的最佳方式.正如#Cruachan所指出的,这个问题可能变成一场噩梦,但它可以通过构建和分发msi包来解决.此类msi包还可以包含所有外部引用,例如"已添加"dll,ocx,tlb文件(报告dll,activeX扫描程序控件等).我们在这里谈了几句.

分发mdb文件的更新版本时,您可以拥有一个公共网络文件夹,其中包含客户端将在启动时检查/更新的新mdb/zipped文件.您的客户端应该可以重新安装以前版本的mdb文件.升级变得比安装新的.exe文件更容易.

您必须设置版本控制系统.请查看此处了解详情.

您必须对代码组织非常严格.我们的基本规则之一是例如在表单级别没有任何特定代码.请在这里查看这个主题.

我没有发现VBA代码扩展有任何问题,如#Cruachan所述.如果实现专业编码规则,则不会出现任何异常的代码扩展问题.作为一个例子,我们的应用程序现在可以很好地工作180多种不同的形式,并且仍在不断增长而没有任何问题.

总之,Access的主要问题是图像问题,微软仍然让人们认为Access可以让他们在10节课中开发真正的软件......而专业人士,知道这是不可能的,查看它作为业余开发的业余工具,将ms-access用户视为无聊的低智商红脖子.

我认识很多专业的Access开发人员,他们使用Access作为前端(MDB或ADP)开发和维护企业级应用程序,并支持100年代的用户群(甚至在少数情况下,数千人).

与任何企业级应用程序开发一样,它需要比为5人部门构建一个小型Access数据库更高级别的编程技能.

奇怪的是,制作高效企业级应用程序的设计原则也使得工作组级别的Access应用程序更加高效.

我认为大多数人在这个帖子中发帖的原因并不能说它是一个好的解决方案,仅仅是因为他们从来没有看到它正确完成,或者他们自己并不同情Access使用的开发模型.

是的,很难做得很好.

但在这个层面上,每个其他开发平台也是如此 - 所有这些平台都需要规划,经验和高级技能.

你可以在没有这些的情况下开发人们开发的Access应用程序(企业与否),但坦率地说,我遇到了大量非各种类型的非Access数据库应用程序,这些应用程序实现得非常糟糕.

鲟鱼定律适用于所有地方,并且没有理由认为Access开发会有所不同.

我开始在Access中使用JET后端进行桌面应用程序.我转而使用SQL Server/MSDE和Access作为前端,然后是VB6和一些经典的ASP.

使用像Visual Studio这样的"真实"开发工具有许多"企业"原因.对于你正在询问的规模,成千上万的用户,我认为这些原因可能适用.

也就是说,我认为有些情况下仍然可以使用Access.根据我自己的经验,当我被授权在很短的时间内提出企业解决方案时,我会回到Access with SQL数据库,尽管这是一个小得多的企业.推动我决定的主要原因是时间.我可以将Access中的数据库UI放在一起,比任何其他工具都要快得多.其中一些是熟悉该工具,但很多是Access只是为您提供更多数据库特定目的位,以便开箱即用.Access UI也可以调整为外观和操作非常类似于标准的WinForms应用程序.

许多企业场景中遇到的障碍是将Access和应用程序MDB/MDE滚动到大众.这可以通过在Windows终端服务器上进行设置来轻松解决,该终端服务器也可以操作,几乎像客户端计算机上的另一个应用程序窗口一样,具有正确的RDP文件参数.但即使这种方法也有其局限性.我认为它不会很好地扩展到成千上万,但对于几十个用户,我发现它工作得很好并且花了足够的时间来满足我必须使用的时间限制,因此可以在时间实现Web界面允许.

对于一个知道他们在SQL数据库中做了什么的专业人士来说,Access前端并不一定是一个不可饶恕的罪,特别是当任务便宜而快速并且没有涉及宗教纯粹主义时.