HeX*_*Xor 3 performance ms-access migration
*.accdb我正在创建一个包含多个表和特定关系的MS Access数据库。
该数据库将用于将数据一次性传输到另一个系统，其中包含数百万个条目的顺序。使用 200 万个虚拟条目进行的测试已达到约 1.8GB 文件大小。由于 MS Access 对每个数据库文件有 2GB 的内置限制，因此我正在寻找绕过此限制的解决方案。
到目前为止我想出了两个想法：
将数据库拆分为两个文件，在从 file1 到 file2 的转换期间继续建立索引，并注意相关表中条目的独立性。
file1_table1 (indices 1..1000)
file2_table1 (indices 1001..N)
使用一个主接口文件将表导出到不同的文件
file1_table1
file2_table2
file3_table3
masterfile (linking table1..3 and creating table relationships)
我想获得一些有关概念、性能和可用性的想法的反馈，或者是否有任何其他想法。
请注意，我想坚持使用 MS Access，构建 SQL 数据库会有点过分，因为它将仅用于一次性传输。
数据分布在多个来源（MS Access .accdb、Excel 表格*.xlsx、分隔文件*.csv），并被分析、合并并准备为临时一次性 MS Access 数据库，然后转换为基于 SQL 的工作数据库，其中包括比我准备的要多得多。所以这是一个经典的 ETL 过程。
“压缩和修复”命令无济于事，因为它实际上只是大量数据，而不是留下大量垃圾的大量操作。“拆分Access数据库”过程似乎只是将查询/表单/报告与包含表的后端文件分开，但我需要拆分表本身，这给我带来了拆分文件之间的一致性问题。这不是接口（前端）和数据后端分离的问题；由于数据量很大，我需要对数据后端本身进行拆分。
您无法绕过 Access 数据库的内置限制。但是，您可以通过使用内置功能（例如在多个*.accdb文件之间拆分数据库对象并相应地引用它们）来规避内置限制。
Access 2016 规范指出：
Access 2016 数据库 (.accdb) 的总大小，包括所有数据库对象和数据：
2 GB，减去系统对象所需的空间。
注意：您可以通过链接到其他 Access 数据库中的表来解决此大小限制。您可以链接到多个数据库文件中的表，每个数据库文件最大可以为 2GB。提示：有关减小数据库大小的详细信息，请参阅使用压缩和修复帮助防止和纠正数据库文件问题。
您甚至可以更进一步，正如您已经提到的，拆分数据和接口。
考虑拆分多人通过网络共享的任何数据库。拆分共享数据库有助于提高其性能并减少数据库文件损坏的机会。
拆分数据库后，您可能决定移动后端数据库，或使用不同的后端数据库。您可以使用链接表管理器更改您使用的后端数据库。
因为它是 Microsoft Access，所以我建议坚持使用受支持的选项，而不是尝试其他可能有效或无效的解决方案。
我们曾经有一个将接口（FE）和数据（BE）分开的应用程序。当托管在文件服务器上时，没有明显的性能差异。但是，当 BE 达到 2 GB 时，写入损坏了 BE 并且数据无法恢复，此时我们决定切换到 SQL Server Express，然后再切换到 SQL Server。我认为当您访问包含不同表的多个 BE 文件时，应该不会对性能产生明显的影响。但将 BE 存储在文件共享上通常会比在本地存储它们慢。