使用 SQLite 数据库作为后端，MS Access 用于前端，超过 2 gigs 的数据 [关闭]

Posted 2023-05-07

【中文标题】使用 SQLite 数据库作为后端，MS Access 用于前端，超过 2 gigs 的数据 [关闭]

【英文标题】：Using SQLite database as backend, MS Access for Frontend, more than 2 gigs of data [closed]

【发布时间】：2019-10-29 21:30:07

【问题描述】：

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

【问题讨论】：

如果我用 GBytes 说话，我会想到 Postgres 或者 mysql —— 或者在你的情况下是 SQL Server 的一个版本。但是，这里不是产品推荐的地方。

【参考方案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 个演出，但您当然必须在独立计算机上设置和运行“服务器”数据库，而且通常不值得花时间设置。

【讨论】：

您可以调整 sqlite 以使用 multiple threads，不过主要用于排序结果。

【参考方案2】：

将 BE 转换为 Access 非常简单，但除非您知道如何“处理”新的 BE 优缺点，否则您不会走得太远，您只会在当前问题中添加问题。 如果您主要关心的是大小，您可以将数据拆分为 1 个以上的 BE（.mdbs、.accdbs），并且仍然保留在 Access 生态系统中。 此外，您必须考虑到 SQLite 更面向单用户，因此如果您要在网络中使用它，这将是有问题的。如果您是应用程序的唯一用户，使用它的一个好方法是保留“访问 Ms Access 中的真实数据并将“额外”数据存储到 SQLite 数据库（如文档、照片等）。

【参考方案3】：

我想我的答案与上面约翰的答案非常相似。此外，您可以使用分析数据库工具并仔细检查您的表是否已标准化。拆分后端数据库。不要将图像和照片存储在 accdb 文件中，而只需在数据库外部为它们创建链接。您可以执行许多措施来减小尺寸。