拆分MS Access数据库 - 只有后端的表？

Question

所以，我正在MS Access中建立这个全新的项目（2007年，但我认为这并不重要），而且我已经接近了将数据库拆分为最终测试和放大器的时间点。 ;部署。拆分设置的因果描述是“BE中的所有表，FE中的所有其他表”，但我想知道是否可能没有一些适当的例外：

1. 我打算在FE中保留一张应用程序管理数据表。这是包含版本号和应用程序标题等信息的一行。它将对用户隐藏。

2. 在跟进相关问题的同时，我看到了BE中一个小型启动表单的想法，它告诉用户（很好地）离开＆amp;反而打开FE。

3. 在我看来，我的查询的一些实际上属于BE。这些特定查询在使用中类似于SQL Server中的视图 - 也就是说，它们将规范化数据一起绘制到更加非规范化的表示中，和/或对一些数据进行“第一次切割”过滤，这些数据全部存储在一起但实际上已经存在一个显着的差异。后者的一个示例是Personnel表，其中BE查询提供了一个子集，这些子集都在同一个部门中，以便在仅与成员关联的表单（或FE查询）中进一步操作该部门。

这些听起来像是合理的做法，还是我应该坚持“所有表格/所有其他”部门？

Answer 1

这似乎是合理的做法，可能除了＃3。将Access DB拆分为前端/后端的关键在于允许您将前端从其他位置移除并对其进行处理，然后替换用户正在访问的版本，而无需替换其数据。你所做的任何不干扰“主要指令”的事都应该没问题。当然，如果你想改变后端架构，后端/前端的区别对你没有帮助，但这就是你在处理Access时得到的，对吗？

＃3可能存在的问题是，您有效地将可能需要进行的任何更改归结为使用架构更改的后端查询。换句话说，如果您需要以任何方式更改这些查询，则需要使后端数据库脱机，就像您在更改架构时需要做的那样。如果你确信没问题，那么这不是问题，但你应该意识到你是以这种方式限制自己。实际上有多少限制取决于那些后端查询的内容。如果它们是你永远不需要改变的东西，除非底层架构也在改变，那么你应该没问题。但是如果他们是那种可能需要改变的东西，因为用户已经改变了他们想要如何呈现这些数据的想法，那么你将会遇到更多麻烦。

Answer 2

将“视图”放在后端无法获得任何性能。应该存储的唯一QueryDef是您在进行模式工作时使用的那些。例如，在我的所有复制应用程序中，我保留了一些显示复制系统表数据的查询。这些都与前端无关。

换句话说，任何属于应用程序的东西都属于前端。从Jet / ACE的角度来看，在性能方面确实没有任何差别，但是你需要做更多工作才能利用这些后端“视图” - 你不能把它们作为一个表链接到它们就像你可以使用ODBC数据源中的视图一样。

Answer 3

第1点：太棒了。版本表确实是应用程序的一部分，而不是BE。您还可以将FE中的信息与BE中的匹配版本进行比较，以确保每个人在需要时进行升级。

第2点：非常好。将它们踢出后端。别忘了禁用旁路键。

第3点：我会说不，永远不会。 BE是（a）你的表（b）关系。如果您需要在应用程序处于生产状态时更改它，请认为其他任何事情都会造成麻烦。它与客户端服务器方法完全不同，在后端合并和过滤的所有内容都是可靠的性能改进，并且您可以在使用应用程序时轻松更改视图（好吧我知道有些人会对此做出反应，但它只要你小心，就可以正常工作：）

Answer 4

编辑：前两段回答了错误的问题，因为我误读了第1点并认为它们意味着用户特定的数据。在重新阅读原始问题时，我同意＃1关于应用程序特定数据。

我不同意＃1并在FE中保留任何本地设置。将本地表与具有网络用户ID的表保持为BE数据库文件中的唯一索引没有任何优势。我们的想法是，在进行更改时替换FE数据库文件应该尽可能简单。每次有新版本的FE时必须导入设置是一件简单的工作。是的，您可以创建查询和代码来完成工作，但为什么还要打扰。

那说我只在本地保留了一个设置，那就是后端数据库文件的位置。为此，我使用了INI文件和API调用。我可以使用注册表项或其他东西。现在，当我在他们的网络上为客户做定制工作时，这并不是真正需要的。这更适用于人们可以从我的网站下载的收缩包装软件。哪个链接表中的数据库位置连接了字符串。

我同意＃2，因为这就是我的工作。

正如大卫所说的＃3不应该做，因为它对你没有任何好处。您需要在FE中使用它们的那些查询

Answer 5

我认为gimmik应该改为“BE中的所有数据，FE中的其他所有数据”。您的前端可能需要保留一些不属于“数据库模型”的表，但属于我称之为“前端元模型”的表：

• 一个简单的例子可以是多语言界面，其中所有文本和标题属性都可以用不同的语言显示。在这种情况下，您可以拥有一个本地\ FE表，该表将包含对应用程序中使用的标题和文本属性的所有引用。
• 另一个示例是当您的应用程序菜单保存在特定表中时，用作在运行时生成特定于表单的菜单/命令栏的源。这样的表也应该在你的FE中。
• 一个“连接”表，将不同的连接字符串保存到类似的数据库（例如会计数据库或同一发布者的不同订阅者）也应该在您的FE上。

您可以选择将这些表保存为xml文件，而不是通过嵌入在FE mdb文件中的表来保存前端元模型。它们最初与您的应用程序一起分发。然后可以分发这些表的新版本（可用连接，更新的翻译等），而无需分发完整的FE文件。

遵循这个逻辑，查询/视图定义肯定是FE元模型的一部分，并且将所有这些视图保存在一个简单的本地XML或嵌入式Tbl_View表中（仅限2个字段：视图名称和视图语法）就可以了。