sql - 使用 SQLite 数据库作为后端，MS Access 作为前端，超过 2 gigs 的数据

Question

我已经使用 Microsoft Access 多年，但不可避免地，我需要迁移到其他数据库系统。现在，SQLite 似乎非常适合我当前的工作环境。我知道拥有一个带有 Microsoft Access 前端的 SQLite 后端非常容易。但是，我也知道 Microsoft Access 数据库在超过 2 gig 时往往会出现问题。我意识到 SQLite 不限于 2 个演出，但是如果我在 SQLite 数据库中说一个 10 个演出数据集并使用 MS Access 作为前端，我会遇到性能问题吗？它可以处理它还是因为后端位于 SQLite 数据库中而无关紧要？我为理解上的无知道歉，但是，如果我一直漫无目的地寻找答案并继续找不到解决方案，那将是 x 10 更无知。谢谢！

标签： sqldatabasesqlitems-accessfrontend

Answer 1

嗯，数据引擎非常快。事实上，在本地机器上，与作为本地实例运行的 SQL Server 相比，使用 JET/ACE 往往会获得更好的性能。

目前尚不清楚 ODBC 驱动程序对于 SQLite 的性能有多好或优化，但这种设置的性能应该与其他任何设置一样快，并且可能比运行某种类型的 SQL 服务器的本地实例更快。公平地说，因为计算机通常具有额外的处理器（内核），所以即使在本地计算机上运行服务器数据库也可以产生更好的性能，因为您使用“更多”处理器来完成相同的工作。

忽略线程问题（据我所知，JET/ACE 和 SQLite 没有线程化，因此您无法真正利用多个 CPU 内核。

但是，从原始性能的角度来看，我怀疑 SQLite 比 JET/ACE 慢，但我从未真正仔细观察过。

几百万行的表对于 ACE/JET 和 Access 来说往往毫无意义，我建议 SQLite 会产生类似的结果，但允许您绕过 2 gig 的限制。我认为如果文件正在推动 2 gig 限制，那么我会考虑为数据库使用基于服务器的系统。但是，如果数据库不是多用户的，那么再次使用基于“文件”的进程内文件数据引擎（如 jet 或 SQLite）不应比使用基于本地服务器的系统造成任何特定的性能损失。

如果一个网络或多个用户开始发挥作用，那么交出一个作为单独进程运行的服务器系统（因此在单独的 CPU 内核上是更好的选择）。

我已经用 Access 测试了 SQLite，但不适用于大文件，所以我不知道它对大表的效果如何。我的意思是，JET 数据库中很容易容纳 5 或 1000 万行，因此不清楚您的数据集有多大，但如果超过 JET，它们必须相当大。SQL Express 是免费的，最多允许 10 个演出，但您当然必须在独立计算机上设置和运行“服务器”数据库，而且通常不值得花时间设置。