有经验的 DBA 应该使用哪种 C# 操作 ms-access 的方法？

Posted 2023-05-07

【中文标题】有经验的 DBA 应该使用哪种 C# 操作 ms-access 的方法？

【英文标题】：Which C# method of manipulating ms-access should a experienced DBA use?

【发布时间】：2019-04-20 21:56:43

【问题描述】：

我想编写一个 Windows 窗体应用程序来与 ms-Access 数据库进行交互。我相当精通 SQL（DB2 和 T-SQL）和 C# - 但不是一起使用。

我应该使用 VS-2019 中对表适配器和数据绑定的支持吗？或者我应该通过 OLEDB 连接编写我自己的 SQLCommands 吗？哪个能让我更快完成？哪个会减少我的挫败感？

我经常对所见即所得感到沮丧，并且在过去（8 年前）使用一些内置的 DataSet 类型接口时遇到了问题。目前，我正在本地进行 ms-access 中的条目/检索 - 但这已经过时了。但我很少使用它所见即所得的东西——我通常只编写自己的查询。

我的 ms-access 数据库已经很好地规范化了——主键和外键的良好分解等。较大的表最多有 1000 行——并且会大致保持一段时间——增长缓慢。这些数据正在跟踪我们的客户以及他们和他们的孩子正在上的课程。这些数据包含个人人口统计数据、课程列表以及每个课程的注册人数 - 包括当前和历史。

在某个时候，我希望将应用程序转移到基于 Web 的实现中，改为访问托管的 SQL DB - 这样我们就可以在任何地方与它进行交互。但是现在要学的东西太多了。

【参考方案1】：

如果您使用 SQL Server、Oracle 或 ms-access 的 oleDB 提供程序，我看不出有什么区别。

那些提供者曾经选择将数据同样好地拉入到所有 .net 对象附近的数据表、数据集和织补中。换句话说，您使用 ODBC 驱动程序来 SQL server 或现在（以及正在折旧的 oleDB 选择）并不是一个大问题。或者你使用 sqlprovder。

我提到的所有这些提供程序都将使用并将数据提取到标准对象集（sqlcommand、数据表等）中。

因此，选择哪个提供商是相当中立的。当然，对于桌面应用程序（独立），那么 Access 作为数据引擎的选择是相当不错的。对于多用户，当然首选一些免费版的 SQL express。

Access 的优势在于与 Excel 的一些额外集成（JET/ACE 引擎可以读取并导出到 Excel。

但是，如果 Access 是一种报告工具，或者您需要与之交互的某些现有桌面应用程序 - 那么使用 JET/ACE 当然是有意义的。

但是，如果您不使用 Access 用户界面而只使用数据引擎？那么你只是选择 X 数据引擎而不是 Y 数据引擎。因此，sqlLite 也是一个不错的“进程中”独立数据引擎，并且像 msaccess 一样是基于文件的。因此，作为基于文件的独立“进程内”，JET/ACE 或 sqlLite 都是不错的选择。

请记住，使用 JET/ACE 数据引擎的另一个重要原因是默认情况下会在所有 windows 副本上安装一个副本（自 windows 98SE 以来一直如此）。

但是，如果您选择内置引擎，则只能使用 mdb（旧格式）文件。如果您需要与一些现有的 Access 应用程序进行一些集成（并且您不仅需要数据引擎），那么您必须使用较新的 ACE 数据引擎来处理 accDB 文件格式。因此，如果作为桌面应用程序不需要与 MSAccess 进行交互，而您只需要一个数据引擎，那么 JET 就可以与 ACE 相比（ACE 是较新的 Access 数据引擎，默认情况下它不安装在 Windows 上，但是与 Access 一起安装，或作为独立下载安装）

另一个考虑因素是 JET 仅提供 x32 位版本。因此，您的 .net 应用程序将作为 x32 而不是 x64 运行“进程中”。如果您的 .net 代码需要与其他 x64（非托管代码）系统交互，那么您不能使用 JET，但有一个 x64 位版本的 ACE 可用）。

因此，在这里使用 Access 或 Oracle 并没有什么不同，您使用 .net 提供程序（oleDB、ODBC）。但如前所述，一旦您选择了这些提供程序，它们都会与生成的 .net 对象（例如表、数据集等）一起使用。

如果将来考虑的是 sql server，那么可以而且应该考虑 SQL express。但是，SQL express 的自动安装和设置本身就是一个完整的项目，而且很痛苦。由于 JET 已经安装在 Windows 上 - 您无需执行任何操作即可使用它 - （甚至不必安装它）。

我同时使用了用于 Access 的 oleDB 提供程序和 ODBC 提供程序 - 没什么大不了的。

【讨论】：

这不是我要学习的特定数据库 - 我正在尝试确定要使用的 C# 访问方法。 - 我可以使用 Visual Studio 的所见即所得的东西 - 与非常好的关系图和数据绑定 - 但是 SQL 对我来说是隐藏的。 - 我可以使用本机对象编写我自己的 SQL - 但是我必须自己跟踪所有 SQL 并填充我的窗口。我不确定哪个会更快 - 从长远来看更容易。我找不到任何列出“并排比较”的内容。

我不知道VS会为Access做关系和图表。您可以在 VS 中使用表格设计器，但除此之外，我不知道 VS 能够做到这一点。你当然可以创建一个实体模型——你可以将它用于任何数据库。但是，在大多数情况下，您可能只使用连接对象。表设计工具将位于 Access 或 SQL Server 或您正在使用的任何系统中（在其他系统中，您可以创建表、设置关系等）。如果说使用 Access，然后想要 SQL Server 的相同代码？我会使用 oleDB 或 ODBC。

也许您的意思是创建数据集的构建器。此类数据集的 sql 是可见的并且可以修改。所以你的问题不是你应该使用什么数据提供者系统（因为它们都工作相同），但你的问题是我应该在处理表单时使用内部数据集构建器，还是简单地写出“内联”的 sql。好吧，选择真的取决于你。对于一个简单的 sql 语句，我只需在代码中直接输入 sql “in-line”即可。如果 sql 很复杂，或者我想使用绑定表单控件（或网格），那么您可以随意使用数据集向导。

【参考方案2】：

从“这将减少我的挫败感”的角度来看，根据您列出的经验以及迁移到托管 SQL DB 的最终愿望，例如 Azure SQL 数据库（本质上是云中的 SQL Server），我会建议您最好利用时间来探索从 Windows 窗体直接转到 Azure 中的 SQL 数据库的选项。

您的数据访问技术本质上是 ADO.net，听起来您有一些经验，其中可能包括您的各种 OLEDB 连接技术，当然还有 EF 或实体框架。

我已经多次遇到您的情况，使用客户端 Access DB 作为数据存储、所见即所得或表适配器以及“轻松链接数据”似乎总是成为一个消耗时间且无法滚动的症结所在从 Access 移动时前进。

根据您提供的问题范围和信息，我只是个人的想法。

【讨论】：

所以 - 我现在应该从 Access 转移到托管数据库吗？这不是一个坏主意。

您寻求整体设计建议，任何人都很难给出明确的答案。你问了一个广泛的问题，除非你变得更具体，否则你将不得不接受一个广泛的答案。根据您的输入，我将转向托管 SQL，因为您指出这是您的最终路径。正如上面古斯塔夫所说，有很多方法可以给这只猫剥皮，很大程度上取决于偏好和经验。

我认为我不是在要求“整体设计”——只是我应该使用内置的所见即所得的东西，还是编写我自己的 SQL。我试图找到一些东西来比较两者之间的优缺点（或者如果还有其他东西） - 什么都没有。

【参考方案3】：

我应该使用 VS-2019 中对表适配器和数据的支持吗 绑定？或者我应该通过 OLEDB 编写自己的 SQLCommands 联系？哪个能让我更快完成？这将导致我更少 挫败感？

我在 VS2005 中开始使用 DatabaseTableAdapters 并没有回头。使用强类型数据表并将 SQL 隐藏起来是一种乐趣。

但是您会发现很多关于此的意见，这在很大程度上取决于偏好和经验。