MS Access 在什么时候比 RDBMS 支持的 Web 应用程序更好？
几年前，我从高中起就没有使用过 Access。
它能很好地解决什么样的问题，甚至比由真正的 RDBMS 支持的 Web 应用程序更好？
它仍然在积极开发吗？或者它对 MS 来说已经死了吗？
它最大的局限性是什么？
更新：
应使用什么资源来学习如何为小型企业开发 MS Access 解决方案？
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
首先，Access 是一个真正的 RDBMS。它并不是客户端服务器 RDBMS。
唯一的含义是同时连接的数量受到限制，并且数据的安全性需要仔细考虑。
除此之外，Access 也是一个使用 VBA 作为语言的 IDE。
这意味着在 Access 中，您可以编写链接到 SQL Server 后端、Access 后端或 SharePoint 后端的前端应用程序。所以它是一种用途广泛的饼干。
它的限制是：
安全性：如果您使用的是访问后端，请注意它没有客户端服务器数据库的内置安全性。在任何应用程序中，安全性都是成本和必要的数据保密性的函数。
同时连接数。如果您不小心，Access 将难以应对超过 10 个人同时尝试更新数据的情况。你可以扩展它，但你需要知道你正在做什么来保证结果。给它一个数字，假设 50 个同时连接。
像大多数数据库一样，它很容易损坏。
注意：当将 Access 称为数据库时，您实际上应该指的是“数据库引擎”、JET 或 ACE，具体取决于版本，对于 Access 2007+，则取决于您使用的文件格式。换句话说，如果您将数据存储在 Access 表中，那么您正在使用 JET 或 ACE。但是，如果您使用的是 SQL Server 等中的链接表，那么严格来说，您并没有对这些表使用 JET 或 ACE 安全性。
Access SQL 不允许您编写存储过程（您可以在 VBA 中编写函数），从某种意义上说，Access SQL 只允许命令式语句而不是过程性语句（例如，控制流语句）。您可以使用 VBA 函数引入一些“过程代码”，但这与使用 SQL 语句有很大不同。
您备份文件本身。您可以通过单击按钮编写代码来执行此操作。
安全始终是成本的函数。如果您拥有价值超过 100,000 美元的数据（无论是权利损失还是被盗而承担法律责任，并且您没有尽职尽责地保护它），那么 Access 可能不是答案。 100,000 是任意数字。确切的数字将取决于数据是否可投保以及数据丢失或被盗的后果。
即，如果数据的价值是主要关注点，那么绝对不要使用 Access 作为后端。是否将其用作前端，是一个预算问题。我花了 5000 美元编写了 10 年后仍在运行的应用程序。他们现在需要将后端移植到 SQL Server，因为敏感数据量已经增加。
当在上述限制范围内使用 Access 时，并且由专业 Access 开发人员（而不是一些认为自己应该使用“更酷”技术的心怀不满的傻瓜）使用时，将以十分之一的成本生成非常复杂、坚固和可靠的应用程序。其他系统。在这种情况下，Access 完全是理所当然的。
其他任何事情都会花费更多，花费更长的时间，并且只能与编写代码和设计 UI 的人一样好。
我有一个应用程序（我在 Access 中构建的第一个应用程序）已经运行了 10 年，没有出现任何问题。我们已经大规模扩展了它。我已经转向 ASP.NET MVC，但 Access 是我的家乡，而且我发现它运行良好。
总而言之：用户数量是相关的，数据中隐含的价值或负债是另一个决定因素。
如果同时用户数较低并且数据的价值/隐性负债较低，那么选择肯定是Access。
但是，让自己成为一名优秀的开发人员。
编辑/澄清：
上面的答案，像所有答案一样，是在工作日中间匆忙写成的。有些陈述有点油嘴滑舌、笼统，而且写得不够精确……但是，当其他人发表的评论合理时，答案的作者应该编辑帖子并澄清。
1/
访问是三位一体的。它是一个 IDE，用于编写在查询中使用的表单、报告和函数。它“包括”一个数据库引擎（JET/ACE）。它为数据库引擎提供了一个可视化界面，允许您设计查询、设置表之间的关系等。
它的许多角色通常被称为 Access，但精度确实有助于学习 Access 并充分利用它。
2/
Access 不能使用存储过程，因为Access SQL 只能使用命令性语句而不是过程性语句（例如，控制流语句）。我一直认为，将它们称为存储过程是有原因的。
3/
并非每个 Access 应用程序的成本都恰好为 100,000。 Access 应用程序的预算也不等于数据的价值。这是显而易见的。我试图传达的想法是，如果数据的价值超过可以合理投保的总和，那么就不要使用 Access。这个数字是十万吗？根据 Access 前项目经理 Luke Chung 和 Clint Covington 的说法，是的，但不要相信他们的话。它实际上只是意味着“很多钱”。
我为医疗慈善机构编写了一个应用程序，在初始预算为 5000 美元后，该应用程序在 10 年后仍然运行。多年来，他们可能又投资了 20,000 美元。此类应用程序是 Access 的最佳选择。
First and foremost, Access IS a real RDBMS. What it is isn't is a client server RDBMS.
The only implications of this are that there is a throttle on the number of simultaneous connections and the security of the data needs careful thought.
Amongst other things, Access is also an IDE that uses VBA as its language.
This means that in Access you can write Front End apps that link to either a SQL Server back end, an Access back end, or a SharePoint back end. So it is one very versatile cookie.
It's limitations are:
Security: if you are using an Access Back End, take note that it doesn't have the built in security of a client server database. In any app, security is a function of the cost and the requisite secrecy of the data.
Number of simultaneous connections. if you are not careful, Access will struggle with more than 10 people trying to update data simultaneously. You can extend that, but you need to know what you are doing to guarantee results. to put a number to it, lets say 50 simultaneous connections.
Like most databases, it is liable to corruption.
NOTE: when referring to Access as a database, you should really be referring to the "database engine", JET or ACE, depending on the version and, for Access 2007+, dictated by the file format that you use. In other words, if you are storing data in Access tables, you are using either JET or ACE. However, if you are using LINKED TABLES, that are in, for example, SQL Server, then you are not, strictly speaking, using JET or ACE security for those tables.
Access SQL doesn't allow you to write stored procedures (you can write functions in VBA), in the sense that Access SQL only allows imperative statements as opposed to procedural statements (eg, control flow statements). You can introduce some "procedural code" using VBA functions, but this is very different to using SQL statements.
You backup the file itself. You can write code to do this at the click of a button.
Security is always a function of cost. If you have data that is worth more than 100,000 US$ (either in loss of rights or legal liabilities if it is stolen and you have not shown due diligence in protecting it), then Access is probably not the answer. 100,000 is an arbitrary figure. The precise figure will depend on whether the data is insurable and the consequences of it being lost or stolen.
Ie, if the value of the data is the driving concern, then definitely don't use Access as a Back End. Whether you use it as a Front End, is a matter of budget. For US$5000 I have written apps that are still running 10 years later. They now need to port the back end to SQL Server because the volume of sensitive data has grown.
Access, when used within the above constraints AND when used by a professional Access developer (rather than some disgruntled fool who thinks he should be using "cooler" technologies), will produce very sophisticated, sturdy and reliable applications at a 10th of the cost of other systems. In such scenarios, Access is a total NO BRAINER.
Anything else will cost more, take longer and will only be as good as the person who writes the code and designs the UI.
I have an application (the first one I ever built in Access) that has run without problems for 10 years. We have extended it massively. I have moved into ASP.NET MVC, but Access is where I hail from and I have seen it work well.
So in summary: the number of users is relevant and the value or liabilities implicit in the data are the other deciding factor.
If the number of simultaneous users is low and the value/implicit liabilities of the data is low, then the choice is definitely Access.
However, get yourself a good developer.
EDITS/CLARIFICATIONS:
The above answer, like all answers, was written in haste in the middle of a working day. Some statements were a bit glib and generic and not written with a suitable degree of precision... However, when the comments made by others are reasonable, the author of the answer should edit the post and clarify.
1/
Access is a holy trinity. It is an IDE for writing forms and reports and functions to use in your queries. It "includes" a database engine (JET/ACE). It provides a Visual Interface onto the database engine that allows you to design queries, set up relationships between tables, etc.
It is usually referred in its many roles as just Access, but precision does help to learn Access and get the most out of it.
2/
Access can't use stored procedures in the sense that Access SQL can only use imperative statements rather than the procedural ones (eg, control flow statements). There is a reason, I have always thought, for calling them stored PROCEDURES.
3/
Not every Access app costs exactly 100,000. Nor is the budget of an Access app equal to the value of the data. That is obvious. The idea I was trying to convey was that if the data is worth more than a sum that can be reasonably insured, then don't use Access. Is that figure 100,000? According to Luke Chung and Clint Covington, ex program manager for Access, yes, but don't take their word for it. It really just means "a lot of money".
I have written an app for Medical Charities that still runs 10 years later after an initial budget of 5000. They have probably invested another 20,000 over the years. That kind of app is the Access sweet spot.
这一切都取决于实际情况，我会给你一个最近发生在我身上的简单例子。在工作中，他们需要一个小型系统来捕获大约 15 个用户组成的组中的一些记录，并将其中大约 15% 的记录传递给另一个大约 5 人左右的团队，以对这些记录执行其他任务。这是一个一次性项目，将持续大约 4 个月。
官方的 IT 解决方案当然是一个带有 SQL 服务器后端的 Web 应用程序，价格约为 60,000 英镑。由于他们没有可用的 SQL 服务器空间并且预算非常小，我决定使用使用 JET 的非绑定访问数据库来存储数据。
在此示例中，access/JET 是正确的选择，如果这是一个支持 500 个用户的长期系统，那么 Web 应用程序当然是最佳选择。归根结底，人们不应该让他们的偏见影响他们的商业决策。
It all depends really, I will give you a quick example that happened to me recently. At work they needed a small system to capture some records from a group of about 15 users and pass about 15% of those records to another team of about 5 or so to do additional tasks on those records. This was a one off project that was going to last about 4 months.
The official IT solution was of course a web app with a SQL server backend coming in at about £60,000. As they had no SQL server space available and the budget was very small I decided to go with an unbound access database using JET to store the data.
In this example access/JET was the right choice, now if this had been a long term system to support 500 users of course the web app would be the way to go. Its horses for courses at the end of the day and people should not let their prejudices effect their business decisions.
啊。绝不。观点。一般而言，限制太多。备份有问题，稳定性也可能有问题。特别是如果您将访问（文件共享数据库）与 Web 应用程序进行比较，您几乎在每种情况下都会陷入痛苦的世界。
Access 可用于小型单处数据库内容（在将数据移至 SQL Server 之前加载数据）或 SQL Server 的前端（即 Access 实际上不存储任何数据）。后者也几乎是微软正在采取的方向——前端技术。
Ah. Never. Point. Too many limitations in general. Backups are problematic, stability CAN be problematic. Especially if you compare access (file share daabase) against web ap you are in for a world of pain pretty much in every scenario.
Access is usable for small single place db stuff (loading data before moving it off to a SQL Server) or a front end for SQL Server (i.e. access not actually storing any data). The later is also pretty much the direction MS is taking access to - a front end technology.
我的知识现在已经很老了，但它过去总是非常适合报表 - 非常快速、强大，并且比 Crystal Reports 等更容易。
My knowledge is quite old now, but it always used to be very good for reports - very quick, powerful, and much easier than, e.g. Crystal Reports.
如果您只是想快速解决某些问题，那么使用 Access 执行至少某些类型的应用程序可能比使用 SQL（或其他）后端的 Web 前端更容易。它仍在开发中（如果没记错的话，Access 2010 是在最近一两个月内发布的）。
我还没有使用过新版本，但我上次查看时，似乎新版本主要是更新外观以与最新版本的 Office 保持一致，清理半明显的问题和错误，但仅此而已。我不会说它已经死了，但我也没有看到太多迹象表明它确实是微软的首要任务之一。
试图确定它的最大限制是很困难的。它所基于的“JET Red”存储引擎根本无法很好地扩展——但它从来没有真正打算这样做。其基本设计旨在将应用程序与存储的数据混为一谈，因此将其视为用于其他目的的原始数据相对困难。我不知道情况是否仍然如此，但至少在某个时候，数据库格式也相当脆弱——文件损坏是半常见的，在大多数情况下，恢复的唯一希望是备份文件（充其量意味着丢失自上次备份以来发生的所有内容 - 并且某些形式的损坏并不立即明显，因此有时也会发生损坏的备份）。
归结为：如果内置到 access 中的向导之一能够准确地生成您想要的内容，或者至少真正的内容，并且您只需要支持很少有用户得到结果，在某些情况下它可能是一个合理的选择。如果这并不（全部）适用，那么几乎肯定会有更好的替代方案。
If you just want to hack something out quickly, it's probably a bit easier to do at least some kinds of applications with Access than a web front end with a SQL (or whatever) backend. It is still being developed (Access 2010 was release within the last month or two, if memory serves).
I haven't used the new version to say for sure, but the last time I did any looking, it seemed like new editions were mostly updating the look to go along with the latest version of office, cleaning up semi-obvious problems and bugs, but not a whole lot more than that. I wouldn't say it's dead, but I don't see much to indicate that it's really one of Microsoft's top priorities either.
Trying to pin down it's biggest limitations is hard. The "JET Red" storage engine it's based around doesn't scale well at all -- but it was never really intended to. Its basic design is intended to conflate the application with the data being stored, so it's relatively difficult to just treat it as raw data to be used for other purposes. I don't know if it's still the case, but at least at one time, the database format was also fairly fragile -- file corruption was semi-common, and in most cases about the only hope of recovery was a backup file (which meant, at best, losing everything that had happened since the last backup -- and some forms of corruption weren't immediately obvious, so corrupt backups sometimes happened as well).
It comes down to this: if one of the Wizards built into access can produce exactly what you want, or at least something really close, and you only ever need to support a few users with the result, it might be a reasonable choice in a few situations. If that doesn't (all) apply, there are almost certain to be better alternatives.
Access 使用的 Jet 数据库引擎已被 Microsoft 视为已弃用，但仍受支持。此处描述了 .mdb 数据库和较新的 .accdb 类型的限制。
链接
甚至在几乎所有情况下，SQL Server Express 都会更好。
对 RDBMS/编程知识非常有限的人仍然可以在 Access 中组合一个快速前端（最好使用外部数据库），这确实是它的主要用途。
The Jet database engine used by Access is considered deprecated by Microsoft, though it is still supported. The limits of an .mdb database and the newer .accdb type are described here.
Link
Even SQL Server Express would be better in almost every case.
Someone with very limited knowledge of RDBMS/programming can still throw a quick frontend together in Access (Ideally using an external database), that's really the main use for it.