MS Access作为企业软件? [英] MS Access as Enterprise Software?

问题描述

我经常遇到用户的问题是他们希望快速获取解决方案，这意味着他们有时会说:哎呀，我只是袖手旁观，并在Access中完成它-它已安装在我的桌面上". /p>

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

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

您对此有何看法?潜在的陷阱有哪些?

OR

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

解决方案

在这种情况下，我已经做了很多工作.实际上，作为顾问/开发人员，Access前端SQL Server后端在过去10年中一直是我从事面包和黄油工作的重要组成部分.这并不意味着我喜欢访问;-)

直到AJAX的普遍采用，这是一个完全合理的解决方案.而且仍然有大量中小型应用程序集成在Access中，它们可以完美地幸福地运行定制的业务系统，而且我怀疑它会在未来10年或更长的时间内消失-实际上Access/SQL可能会成为21世纪的Cobol.如果您正在绿色领域"站点上工作，那么从头开始构建时几乎没有任何借口来部署Access-但是，如果您确实继承了现有应用程序，那么重写的成本可能就不值得并且很难通过用户.

访问确实仍然具有一些明显的优点-如果建议转换为Web应用程序，则可能会带来问题

1. 很快.对于简单的CRUD工作，它可以像编写任何其他实际解决方案一样快地编写和部署.
2. 内置报告易于运行，并且在系统给定的情况下功能非常强大.通常，按需为用户创建和部署新报告非常容易.
3. 它与Office很好地集成在一起.当希望将Access应用程序移动到Web应用程序时，该程序往往是止步不前. 部门大小"的Access应用程序紧密与Outlook，Word或Excel集成，并且经常与这三个集成非常普遍. 在处理现实情况时，这是主要问题.编码人员很容易低估了此功能对于此类系统的日常使用的重要性，并且通常给用户带来即使是很小程度的额外麻烦也常常会遇到很大的阻力-通常足以完全破坏项目.
4. 如果您在一个合理规模的部门工作-大约十几个人-在办公室里有人会幻想自己像个计算机向导，这是很普遍的.如果处理不当，这些人可能会感到很痛苦，但同样会成为主要财富.如果我有这样的人，我将尝试让管理人员将其发送给一两个Access课程，以便他们可以编写简单的查询和报告，并为他们自己拥有的 设置一个单独的Access应用程序.对SQL数据库具有适当的(受限制的)访问权限.然后，您可以信任此人为同事处理简单的报告等.这可能是真正的双赢-您获得了一个在您身边并会担任您辅导员的人-该部门为您准备的现成倡导者-并且他们使笨拙的报告工作不至于浮出水面.他们获得了很多荣誉和工作满意度，甚至获得了潜在的职业发展道路.用Access以外的任何其他系统来做这种事情要困难得多，几乎是不可能的.

主要的实际缺点

1. 部署可能是一场噩梦.通常，如果您有一个非常严格定义的环境-一家小型公司，单个部门，基于citrix或与IT部门一起分布的IT部门可以严格控制其PC，那么您就可以了.作为跨多个公司的商业应用程序进行部署-仅当您可以收取大量维护费用时才可以使用.
2. 代码无法缩放.即使由专业人士编写，也要访问VBA代码，很容易腐烂成乱七八糟的意大利面.最终会获得一个易于维护的Access应用程序，但是随着依赖关系的增加，它逐渐变得不可维护.

所以我想说Access仍然占有一席之地，它的使用在许多现实世界中都是可以辩护的，但是如果情况允许，最好选择一个更现代的解决方案.

Something that I often run into with my users is their desire to aquire solutions quickly means that they sometimes have said "Heck, I'll just roll up my sleeves and do it in Access - it's installed on my desktop".

Sometimes, we're lucky and the person that creates the Access database back-ends it to a SQL Server, so at least the mdb file issues that often come up aren't an issue.

However, it is my opinion that rolling out an Access front-end to a SQL Server database as an enterprise solution with thousands of users, and hundreds of thousands of rows is still problematic.

What are your opinions on this? What are some of the potential pitfalls?

OR

Is this a perfectly acceptable, stable, maintainable, and robust solution?

解决方案

I've worked with this scenario a great deal. In fact as a consultant/developer Access front end SQL Server back end has been a significant part of my bread and butter work over the past 10 years. Which doesn't mean I like Access ;-)

Up until the common adoption of AJAX it was a perfectly reasonable solution. And there's still vast numbers of small to medium sized applications put together in Access out there that run bespoke business systems perfectly happily and I doubt it's going to go away for the next 10 or more years - indeed Access/SQL is probably going to be the Cobol of the 21st century. If you're working on a 'green field' site then there is now virtually no excuse for deploying Access when building from scratch - but if you do inherit an existing application then the costs of a rewrite may not be worthwhile and difficult to pass with the users.

Access does have some advantages that are still significant - and can present problems if proposing to convert to a web app

1. It's quick. For simple CRUD work it's as fast to write and deploy as any other realistic solution.
2. Built-in reporting is easy to get running and remarkably powerful given the system. It's usually pretty easy to create and deploy new reports for users on demand.
3. It integrates well with Office. This one tends to be the show-stopper when looking to move Access apps to web-apps. It's extremely common for a 'department-size' Access application to tightly integrate with Outlook, Word or Excel - and often all three. This is the major problem when dealing with real-world situations. It's very easy for coders to underestimate the importance of this for everyday usage of such systems and the imposition of even a small degree of additional hassle for the users will generally be met with much resistance - often enough to completely scupper the project.
4. If your working with a reasonable sized department - a dozen people or so - it's quite common for there to be someone in the office who fancies themselves as a bit of a computer wizard. These people can be a major pain if handled incorrectly, but equally can be a major asset. If I have such a person I will try to get management to send them on an Access course or two so they can write simple queries and reports, and set up a separate Access application for them which they own which has appropriate (restricted) access to the SQL database. You can then trust this person to handle producing simple reports and the like for their colleagues. This can be a real win-win - you gain someone who is on your side and will use you as a mentor - a ready-made advocate for you in the department - and they keep the grunt report work out of your hair. They gain a lot kudos and job satisfaction - and even a potential career path. It's far harder, well near impossible, to do this kind of thing with any other system but Access.

Main practical disadvantages

1. Deployment can be a nightmare. Generally if you have a very tightly defined environment - a small company, single department, citrix based or distributed with an IT department that closely controls it's PCs then you're fine. Deployment as a commercial app across multiple companies - well only if you can charge significant maintenance (been there).
2. Code does not scale. Access VBA code, even when written by a professional has a strong tendency to rot into rancid spagetti. It's quite common to end up with an Access application that was easy enough to maintain, but gradually becomes unmaintainable as dependencies multiply.

So I'd say Access still has a place, and it's use is defendable in many real world situations, but increasingly it's better to choose a more modern solution if circumstances permit.

这篇关于MS Access作为企业软件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！