关于 MS Access 数据库的几个问题 -
大小：访问数据库的大小是否有限制？我问的原因是我们有一个包含几个简单表的访问数据库。数据库的大小约为 1GB。当我对其进行查询时，我发现它需要 10 多分钟才能运行。
通过适当的索引，MS Access 是否应该能够处理此问题，或者该技术是否存在基本限制。
这是 MS Access XP。
此外，MS Access 是否支持数据库事务、提交和回滚？
akantro
问问题
3910 次
8 回答
4
你会在这里得到很多不同的答案，但在我的观点中，访问并不是一个可扩展的解决方案。它不能很好地处理多用户情况，当您开始接近 1Gb 大小时，稳定性开始成为主要问题，实际上它只是没有性能。
关于事务支持，请参阅此 Microsoft文章。
此外，这里有一篇文章实际上指出了大多数访问限制。
于 2008-10-07T18:37:02.033 回答
2
作为回答——
大小：Access 数据库的最大大小为 2GB。
事务：底层 JET 数据库引擎完全支持事务。
根据过去的经验，我倾向于说您可能已经达到了最大可用大小，并且可能应该考虑升级到 SQL Server Express。
于 2008-10-07T18:48:00.793 回答
0
就个人而言，我发现“可用”限制在几百兆字节范围内。
Access 是为小型数据库设计的。对于大型的，即不仅仅是你和几个人正在使用的东西，你应该看一个“真正的”RDBMS，比如 SQL Server、ORacle、DB2、MySQL 等。
编辑- 请参阅http://www.blueclaw-db.com/vb_transaction_processing.htm了解使用 Access 处理事务的方法。显然不是原生的。
于 2008-10-07T18:38:21.563 回答
0
Access 数据库的最大大小为 2GB。您可以通过在其他文件中使用链接表来解决此问题，但如果您已经遇到性能问题，可能是时候使用更强大的数据库了。
我的建议是查看SQL Server Compact，它是一个免费的基于文件的数据库，或者更好的是SQL Server Express，它是支持多个用户的 SQL Server 的免费“精简”版本以及与 SQL Server 的互操作性。两者都将您限制为 4GB 数据库。
所有提到的产品，包括 Access，都支持事务。
于 2008-10-07T18:42:42.973 回答
0
我不确定它们是否还在 XP 版本中，但在 Access 97 中，有压缩和修复选项。如果这些仍然是选项，它们可能会有所帮助。
于 2008-10-07T18:51:05.657 回答
0
虽然这可以追溯到很多年前，当时进入 SQL Server 安装的成本与 Oracle 一样高，但我的一个客户正在使用 Access 尝试管理呼入呼叫中心。
我们正在谈论 VLDB——4000 万行的超大型数据库概念。这是在电话公司推出来电显示并为其订户提供一种免费来电显示设备的时代。由于成本限制，他们不得不无视我对 SQL Server 投资的请求。
在实践中，Access 似乎以大约 800MB 的速度崩溃。我们将表分区到多个 Access 数据库中来处理负载。信不信由你，它工作得很好。客户很感激。
在实践中，考虑到 SQL Express 的可用性，我也建议走这条路。
于 2008-10-07T18:53:26.243 回答
0
多年来阅读 Access 新闻组的印象是，现在仅在将 MS Access 用作使用绑定表单的基于 RAD 表单的开发环境时才推荐使用 ACE/Jet 引擎（.accdb、.mdb 或 .mde 文件）。如果您没有 Access 前端，那么在考虑更具可扩展性（和功能）的替代方案时，很少有支持 ACE/Jet 后端的论据：用于 MS 商店的 SQL Server Express 或 SQL Server Compact Edition、MySQL、等等
正如 ACE/Jet 引擎中的事务支持一样，是的，它存在并且是原生的。另一个答案链接到一篇关于通过 DAO 使用事务的文章：请注意，DAO 的许多方面都受到限制，因为它的开发落后于引擎，事务就是一个例子。令人高兴的是，您可以使用 SQL DCL：BEGIN TRANSACTION、COMMIT TRANSACTION、ROLLBACK TRANSACTION 等来完成 DAO 无法完成的事情，例如嵌套事务。SQL DCL 要求 Access 接口处于 ANSI-92 查询模式；使用 ADO 将起作用，因为 ADO 本身就使用此模式。有关更多详细信息，请参阅：
于 2008-10-08T09:52:05.900 回答
0
Jet 可以成为任何数量的桌面开发平台的非常好的数据存储，而不仅仅是 Access 本身。它一直是 VB 开发人员的首选，现在仍然是（有充分理由）。
预计不会大幅增长的 1GB MDB 在速度或可靠性方面应该不是问题。如果它很慢，那么你没有正确索引它，或者你正在编写非常低效的 SQL。低效 SQL 的一个例子是将 WHERE 子句应用于表达式，因此不能使用索引——一个例子是
WHERE Year([MyTable].[MyDate]) = 2002
与
WHERE MyTable.MyDate Between #1/1/2002# And #12/31/2002#
如果您遇到稳定性问题（即经常性损坏），这是一个需要解决的问题——通常是由于人为错误、硬件问题或软件问题（如 AV 软件干扰内部 Jet 写入操作）。
But the key determinant is how fast the MDB is growing. If you extrapolate out the historical growth rate and approach 2GBs within 5 years, I'd say you need to upsize soon. If it's more like 10 years, you should probably do it anyway. If it's 20 years, then, not so much.
于 2008-10-08T16:55:05.810 回答