如果我使用access/jet作为Web应用程序的后端,我应该关注哪些问题?

你面临的一个关键问题是 可利用性 . 具体来说,需要锁定用户以进行修复和备份,这对于典型网站的24/7可用性需求可能不现实。

并发性是您的问题。一个设计良好的AccessDB通常可以支持多达50个用户,甚至可能支持几百个,这取决于所需的特定访问类型(例如只读)。但是,随着应用程序进行大量更新,您将比使用大多数客户机-服务器类型的数据库包更快地遇到并发问题。

忽略有关数据库大小方面的可伸缩性的任何注释。对于大多数应用程序,在这方面您不会接近MS访问的限制。

另一方面,通过切换到客户机-服务器数据库,可以增加很多复杂性和成本。所以,如果你正在建立一个小型的内部使用网站,访问也可以是一个合理的选择。这一切都是为了使您的需求与技术相匹配。

数据大小是另一个问题。对于更大的尺寸,您需要更严格的数据库引擎。

可扩展性、可用性和备份支持。

问题是,它无法扩展——而且实际上也不是有意的。你必须为这项工作选择合适的工具。

现在就避免麻烦,选择SQL Server(有免费版本-如果您符合BizSpark的条件,您可以 强大的 免费版本)、mysql或postgres。

没有人提到的是,Jet/Ace后端的工作情况(从网站的角度来看,没有访问后端)取决于您使用什么接口来访问其数据。

如果使用ODBC或DAO,可能会遇到问题,因为两者都不是线程安全的。但是通过OLEDB/ADO Classic访问,您可以获得线程安全访问。因此,在Web应用程序中使用jet/ace数据存储的唯一可行方法是OLEDB/ADO Classic。

(我正在报道迈克尔·卡普兰说过的很多次,他对喷气式飞机的遗忘比我所知道的要多得多。)

根据我的经验,Access数据库在分配空间方面似乎很差,因此它们的大小比预期的要大。我还遇到了数据损坏问题。

如果有人打开数据库进行编辑,这可能会锁定其他连接。

虽然所有的数据库都需要维护,但是尝试在一个非常大的数据库(1GB+上)上运行“维护”(压缩和修复),然后看看会发生什么。它不仅有可能锁定用户,而且很可能破坏整个系统