XML vs. SQlite vs. Access答案

【问题标题】：XML vs. SQlite vs. AccessXML vs. SQlite vs. Access
【发布时间】：2010-12-29 01:31:45
【问题描述】：

问题：我们为客户启动了一个项目，其中包括通常使用数据库完成的工作。

但是，客户不希望安装数据库，因为它只是一个小应用程序。然而，我们打算将代码重用于更大的项目，该项目将使用数据库。

问题是，如果我使用 XML、SQlite 或 Access，所有服务器端代码都会有所不同。

我倾向于 SQlite，但我不知道。在 MS-Access 文件中添加数据库会是更好的解决方案吗？如果我将其放入访问数据库，客户是否需要安装 MS-Access 或仅安装 MSFT MDAC？如果我使用 Access DB，它是否也可以在带有 Mono 的 Linux 下运行，还是没有 MDAC 替代品？

【问题讨论】：

我希望您打算向客户收取所有额外工作的费用......他知道这是因为他不需要数据库。

标签： asp.net xml ms-access sqlite

【解决方案1】：

所有最新版本的 windows 一直到 windows 7 都附带了 JET（ms-access 数据引擎）的副本。所以，你根本不需要 mdac，也不需要安装 ms-access。

您甚至可以在没有安装任何软件的情况下在干净的 windows 盒子上编写 windows 脚本，因此您可以从 mdb (ms-access) 文件中读取数据。

所以，这里的问题不在于安装，因为“JET”（ms-access 使用的数据库引擎）无论如何都是随 windows 一起提供的。

我认为这里唯一的例外或考虑因素是您是否计划使用 64 位版本的操作系统并使用进程内 64 位应用程序？

Office 2010 有一个 64 位版本的 ms-access，据我所知，还有一个单独的下载，用于在 64 个机器上安装 JET（现在称为 ACE）引擎。

如果您打算只在 32 位机器上工作（或在 64 位机器上使用您的软件的 32 位版本），那么您不需要 ms-access 也不需要安装任何东西来读取和使用 mdb（ms -访问文件）。

由于 JET 随附所有最新版本的 windows，您的决定将不会基于安装 JET（您不必），您的决定将是其他问题以及 JET 是否满足您的要求。

【讨论】：

我在 64 位 Hasta-la-Vista 机器上开发。当我安装 64 位 Office 2010 时，我必须安装 MDAC，它不能开箱即用。可能是因为我卸载了office 2007，可能是因为它是64位机器，或者是因为预装的JET/ACE已经过时了。所以我认为它应该包含在安装程序中。
Windows 附带的 Jet 版本是 32 位 Jet，因此您必须针对 i386 进行编译，因为 32 位库不能在纯 64 位可执行文件中使用。安装 A2010 或卸载 A2007（或安装/卸载任何版本的 Access）对 Jet 没有任何影响，因为它是一个操作系统组件，无法删除。

【解决方案2】：

在中等信任环境（例如共享主机）中使用 sqlite 可能会遇到问题。如果您愿意接受其他解决方案，您可以考虑尝试VistaDB。所有主要的 orm 都支持它（nhibernate、openaccess、实体空间、亚音速等等）。

【讨论】：

我不会使用仅限 Windows 的解决方案。如果我的同事这样做就够糟糕了。
我不确定，但我认为 VistaDB 可以在单声道上运行。
Jet 是一个仅适用于 Windows 的解决方案，所以您想从原来的问题中编辑它吗？
@David W. Fenton 你能澄清一下这个说法吗？ stackoverflow.com/questions/1667583/… 表明您可以在 Linux 中使用 Jet。
您可能正在读取/写入 MDB 文件，但您没有使用 Jet，我不能说我认为它是一个可行的解决方案。对像 Jet 这样复杂的东西进行逆向工程并不是一件小事，这就是为什么，例如，MDB Tools 项目从未超越只读访问权限。

【解决方案3】：

您无需安装 Access 即可使用 Jet 引擎。据我所知，Jet 安装在所有最新版本的 Windows 中。您可以使用Jet (Access) with Linux。与包括 SQLite 在内的替代方案相比，Jet 在数据库管理方面的要求非常低。

【讨论】：

【解决方案4】：

我会考虑使用NHibernate，您可以将它连接到 SQLite，但可以稍后升级到完整的数据库，而无需更改太多代码。如果您对此不感兴趣，我会直接在 XML 文件上使用 SQLite。

【讨论】：

+1 用于 SQLite。此外，您不必使用 ORM 来获得正确的 3 层实现。只需确保您的 DAL 可以轻松替换（例如使用接口），并且您的 BLL 中不存在 DAL 逻辑（不用说演示）。
NHibernate 的 +1。您不需要 ORM，但它让它变得更容易。

【解决方案5】：

我会使用 SQLite 而不是 Access - 对于 SQLite，您只需要提供 DLL，对于 Access，您需要一个安装程序（尽管我认为它已内置到最新版本的 Windows 中）。 SQLite 也是一个更好的数据库。

或者您当然可以使用存储库模式或类似模式来抽象数据存储机制？如果您要将数据存储在一个文件中，然后使用 Linq-To-Objects 从存储库中加载并公开它，然后您可以直接将其替换为 Linq-to-SQL 而无需更改任何客户端代码.

【讨论】：

我已经有该项目的安装程序，我认为向 Access MDAC 添加依赖项不会有太大问题。
不过，我还是会选择 SQLite；使用 Access 烧录了太多次。虽然如果它是一个像你说的小项目，你可能没有什么可失去的。如果您打算在更大的项目中使用代码，尽管我建议存储库层的开销是值得的。