前几天有人问过我，我想不出一个好的答案。平台可移植性与项目完全无关。
事实上，Jet有一些SQLite没有的功能，即外键。
那么有谁能想到为什么应该使用SQLite而不是Jet数据库呢？
答案 0 :(得分：23)
与其他人的说法相反，Jet并没有死，而且远非如此：ACE是Jet的新版本，它非常强大且向后兼容。
SQLite和Jet / ACE都有自己的优点和缺点，您需要获得有关对您和您的应用程序很重要的特定点的更多信息。
那些说Jet破坏数据库的人在1995年陷入困境。
最后，除非你的应用程序有一些非常具体的要求推动了数据库引擎的界限，否则你选择哪一个并不重要。
只需使用最容易包含在项目中的那个。
答案 1 :(得分：7)
SQLite优于Jet，主要原因是SQLite为ACID-compliant，而不幸的是，Jet不是。{如果数据完整性是一个问题，SQLite为您的数据存储需求提供了一个更加“强大”的平台。有关详细信息，请参阅"SQLite Is Transactional"和"Atomic Commit In SQLite"。
SQLite确实缺少一些功能（例如外键），但是，这些主要是由于SQLite被专门开发为一个非常小且轻量级的数据库，也是无服务器的。
SQLite的无服务器方面也是Jet的一个主要优点，因为不需要在运行数据库的机器上安装任何东西。例如，我在ASP.NET Web应用程序中使用了SQLite，我需要的只是SQLite DLL（在这种情况下是我的应用程序的“bin”文件夹中的优秀System.Data.SQLite替代品），而我的应用程序的“App_Data”文件夹中的数据库。然后我可以将这些文件上传到我的虚拟主机，这一切都“正常”。这无需实际安装或在目标计算机上注册任何内容。
SQLite的一小部分是由于数据库是基于文件的。数据库写入将锁定整个数据库文件而不是特定的行或表，而Jet将为您提供更精细的锁定级别。基于相同的基于文件的推理的另一个小问题是并发性，但Jet本身也不提供高级别的并发性。
答案 2 :(得分：6)
这仍然是一个不时出现的问题。我正在考虑现在为一个新项目的所有利弊。我写了很多处理金钱价值的金融应用程序，因此对于Access / JET / ACE /其他任何人来说，最重要的“专业人士”之一（我称之为Access）是其强大的类型。当你处理钱时，不要低估拥有强大类型的强大功能 - Access是我见过的唯一一个支持可存储REAL货币值的货币/小数类型的单文件数据库。
我的一个主要零售产品使用SQLite作为后端，我可以告诉你，即使在最疯狂的情况下，我也几乎没有问题。 SQLite绝对是单用户设计的，但我有很多客户通过SMB使用它。你必须在你的软件中写入检查，以便在运行查询时检查SQLITE_BUSY的返回值，但是如果你用自动重试将其包装起来就“正常工作”。
我选择Access over SQLite只有几个原因 - 一个是数据类型。如果我一直在编写必须对货币价值（税等）进行数学计算的软件，我将使用Access。使用Access的唯一其他令人信服的理由是SQL Server的升级路径。因为我一生中从未使用过SQL服务器（并且不打算这样做），所以这不是什么大问题。
最后，两者都是非常强大的数据库 - 我会毫不犹豫地在生产环境中使用它们。只记得使用正确的工具来完成工作，有时这意味着数据库服务器（PostgreSQL在过去的13年里一直对我这么做，这是肯定的！）。
答案 3 :(得分：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驱动程序（只是Google）。效果很好。
SQLite在32位和64位都可以正常工作。如果您阅读它，您将看到它经过严格测试并且非常稳定。它还支持更多标准SQL，并且比Jet更接近Oracle / SQL Server。
答案 4 :(得分：4)
不再支持Jet。 SQLite也更容易安装，因为它是一个可以轻松与您的应用程序打包的DLL。使用SQLite也可以防止供应商锁定，因为语言或跨平台的可移植性现在不是一个问题，并不意味着它不会成为一个以后。有关Jet退休的更多信息，请参阅 http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
答案 5 :(得分：2)
成本不是问题。如果您的前端是使用MS-Access以外的其他方式构建的，则应用程序的用户无需支付任何费用即可安装Jet驱动程序。 Visual Studio将在构建期间包含这些驱动程序（至少在.NET之前的版本中。）。
我猜你没有个人偏好，并且在任何一种环境中都具备相同的开发技能。如果您的用户已经拥有MS-Access许可证，并且他们希望能够编写自己的报告（哦，上帝禁止任何非黑客尝试这么大的壮举！），请使用Jet。
答案 6 :(得分：2)
SQLite是新的Jet。即使跨平台与您无关，也可能不是您的客户。使用Jet将它们锁定到Windows和不再支持的数据库，这两者都不是好事。 SQLite适用于任何开发环境。
Jet以出现奇怪的腐败问题而闻名，因此我倾向于远离它。
您当然可以在SQLite中创建外键，并且从SQLite 3.6.19开始也添加了外键约束。
答案 7 :(得分：0)
离开我的头顶，它是自由的和跨平台;但更重要的是......你认为它比Jet / MS Access / .mdb更稳定和可扩展吗？它的后继者（ACE / .accdb）
会更长寿吗？如果不仅仅是几个人使用它，我也不会打扰Jet。我直接进入MS-SQL（甚至免费版本）。这不值得腐败DB的痛苦（Jet是众所周知的 - 虽然他们可能已经解决了 - 但我不想成为他们的测试案例。）
答案 8 :(得分：0)
如果您使用Python，Pearl，Lua或许多其他语言编写得很好，SQLite将是您的理想选择。