22

前几天有人问我这个问题，我想不出一个好的答案。平台可移植性与项目完全无关。

事实上，Jet 有一些 SQLite 没有的特性，即外键。

那么谁能想到为什么应该使用 SQLite 而不是 Jet 数据库？

4

9 回答 9

23

与其他人所说的相反，Jet 并没有死，而且离它还很远：ACE 是 Jet 的新版本，它非常健壮且向后兼容。

SQLite 和 Jet/ACE 都有其优点和缺点，您需要获取有关对您和您的应用程序很重要的特定点的更多信息。

  • 无论哪种情况，您都可以重新分发引擎。
  • Jet/ACE 在 MS 工具和 Visual Studio 中的集成度更高，并且支持开箱即用。
  • Jet/ACE 具有更细粒度的锁定，如果您的应用程序允许多用户或需要多线程访问数据库，这可能很重要。
  • 就您对数据库的期望（连接、联合和复杂查询）而言，Jet/ACE 具有更多功能。
  • Jet/ACE 具有到 SQL Server 的简单迁移路径，因此如果您的数据库需求变大，您可以相当轻松地迁移到 SQL Server。
  • SQLite 是跨平台的，所以如果你的应用需要移植到 Mono 下的 Linux/Mac 上，那么 SQLite 是一个更好的选择。
  • SQLite 引擎更紧凑，因此重新分配可能更容易。
  • SQLite 中的数据类型非常松散。
  • SQLite 拥有更自由的再分配权（因为你基本上可以用它做任何你想做的事）。

那些说 Jet 破坏数据库的人被困在 1995 年。

最后，除非您的应用程序有一些非常具体的要求正在推动任一数据库引擎的界限，那么您选择哪一个可能并不重要。
只需使用最容易包含在项目中的一个即可。

于 2009-02-12T11:13:58.767 回答
7

SQLite 优于 Jet 的主要原因是 SQLite符合 ACID 标准，而不幸的是，Jet 不符合。如果数据完整性是一个问题，SQLite 为您的数据存储需求提供了一个更加“强大”的平台。有关详细信息，请参阅“SQLite 是事务性的”和“SQLite 中的原子提交”。

SQLite 确实缺少一些功能（例如外键），但是，这主要是因为 SQLite 是专门开发的，它是一个极小且轻量级的数据库，也是无服务器的。

SQLite 的无服务器方面也是 Jet 的一个主要优势，因为它不需要在运行数据库的机器上安装任何东西。例如，我在一个 ASP.NET Web 应用程序中使用了 SQLite，而我所需要的只是应用程序的“bin”文件夹中的 SQLite DLL（在这种情况下是出色的System.Data.SQLite替代品），以及我的应用程序的“App_Data”文件夹中的数据库。然后我可以将这些文件上传到我的虚拟主机，这一切都“正常工作”。这无需在目标机器上实际安装或注册任何东西。

SQLite 的一个小缺点是由于数据库是基于文件的。数据库写入将锁定整个数据库文件而不是特定的行或表，而 Jet 将为您提供更精细的锁定级别。基于相同的基于文件的推理，另一个小问题是并发性，但是 Jet 本身也不提供高级别的并发性。

于 2009-02-12T10:52:21.547 回答
6

这仍然是一个不时出现的问题。我现在正在考虑一个新项目的所有利弊。我写了很多处理金钱价值的金融应用程序，所以 Access/JET/ACE/whatever-theyre-call-it-today（我只是称之为 Access）最重要的“优点”之一是它的强类型. 在处理金钱时不要低估强类型的力量——Access 是我见过的唯一一个支持可以存储真实金钱值的金钱/十进制类型的单文件数据库。

我的一个主要零售产品使用 SQLite 作为后端，我可以告诉你，即使在最疯狂的情况下部署它，我也几乎没有遇到任何问题。SQLite 绝对是为单用户设计的，但我有很多客户在 SMB 上使用它。您必须在软件中写入检查以在运行查询时检查 SQLITE_BUSY 的返回值，但如果您使用自动重试将其包装起来，它“就可以工作”。

我选择 Access 而不是 SQLite 的原因只有几个——一个是数据类型。如果我曾经编写必须对货币价值（税等）进行数学运算的软件，我将使用 Access。使用 Access 的唯一另一个令人信服的原因是 SQL Server 的升级路径。由于我一生中从未使用过 SQL Server（也不打算使用），所以这没什么大不了的。

最后，两者都是非常强大的数据库——我会毫不犹豫地在生产环境中使用它们。只要记住使用正确的工具来完成这项工作，有时这意味着数据库服务器（PostgreSQL 在过去 13 年里一直在对待我，这是肯定的！）。

于 2011-03-27T20:29:48.060 回答
5

我们使用 Jet 很长时间，最近切换到 SQLite。为什么？

1：当数据库接近 2 GB 或频繁使用时，它最终会在 Jet 中损坏。这给我们带来了很大的悲痛！这在 Jet 或 ACE 中没有得到修复，尽管微软有一个单独的工具可以修复数据库文件。

2：微软几年前就弃用了 Jet，转而支持 ACE，但如果您阅读详细信息，微软自己说 ACE 不是 Jet 的替代品，并且真的希望您使用 SQL Server 来代替。

3：Jet 不再是 Windows 的标准部分，而是 Microsoft Office 的一部分，尽管您可以下载并安装分发包。但是，您不能同时安装 32 位和 64 位引擎。如果您安装了 Office 2007 32 位，并且您尝试安装 64 位 ACE 引擎，它会告诉您需要先卸载 Office 2007。

因此，出于这些原因，我们只是决定足够了。安装 SQL Server 不是一个解决方案，因为它是一个大型复杂的侵入式安装，并且不是很便携。

我们的 C++ 软件通过 sqlite3.c 文件直接支持 SQLite，效果很好。我已经为 OCILIB、Oracle、SQL Server、MySQL 等实现了反接口，这是最简单的接口之一。它也比 Jet 快得多，生成的文件可能是 Jet 大小的三分之一。我们确实有一些 VB6、VBA 和 .NET 代码，它们也需要使用我们的数据库文件，为此我们使用 SQLite ODBC 驱动程序（只需谷歌它）。效果很好。

SQLite 在 32 位和 64 位上都可以正常工作。如果你阅读它，你会发现它经过了严格的测试并且非常稳定。它还支持更标准的 SQL，并且比 Jet 更接近 Oracle/SQL Server。

于 2011-06-08T03:15:19.973 回答
4

不再支持 Jet。SQLite 也更易于安装，因为它是一个可以轻松与您的应用程序打包的 dll。使用 SQLite 还可以防止供应商锁定，仅仅因为语言或跨平台可移植性现在不是问题并不意味着以后不会成为问题。有关 Jet 退休的更多信息，请参阅 http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine

于 2009-02-03T05:59:51.413 回答
2

成本不是问题。如果您的前端是在 MS-Access 以外的其他东西中构建的，则应用程序的用户无需支付任何费用即可安装 Jet 驱动程序。Visual Studio 将在您的构建过程中包含这些驱动程序（至少 .NET 之前的版本包含。）。

我猜你没有个人偏好，并且在任何一种环境中都同样擅长开发。如果您的用户已经拥有 MS-Access 许可证并且他们希望能够编写自己的报告（哦，上帝禁止任何非黑客尝试如此巨大的壮举！），请使用 Jet。

于 2009-02-03T13:50:45.957 回答
2

SQLite 是新的 Jet。即使跨平台与您无关，也可能与您的客户无关。使用 Jet 将它们锁定到 Windows 和不再受支持的数据库中，这两者都不是好事。SQLite 几乎可以与任何开发环境一起使用。

Jet 以有奇怪的腐败问题而闻名，所以我一般倾向于远离它。

您当然可以在 SQLite 中创建外键，并且从 SQLite 3.6.19 开始，还添加了外键约束。

于 2009-02-03T14:05:36.347 回答
0

在我的脑海中，它是免费且跨平台的；但更重要的是……你认为它比 Jet/MS Access/.mdb 更稳定、更可扩展吗？它的继任者会更长寿吗 (ACE/.accdb)

如果它被不止几个人使用，我不会打扰 Jet。我直接使用 MS-SQL（甚至是它的免费版本）。只是不值得为损坏的数据库而痛苦（Jet 以它而闻名 - 尽管他们可能修复了它 - 但我不想成为他们的测试用例）。

于 2009-02-03T06:15:44.393 回答
0

如果您使用 Python、Pearl、Lua 或许多其他语言进行良好的编程，SQLite 将是自然的选择。

于 2013-09-16T20:59:41.193 回答