MDB 数据库文件移到异地

Question

使用基于 MDB 的应用程序的大型客户端已将 MDB 文件移至异地，以便我的应用程序通过 WAN 连接到它。

我怎样才能说服他们将 MDB 文件放回现场的 LAN 上，以便应用程序能够可靠地运行？

我能说所有的数据库都必须在局域网上吗，不管是什么类型的数据库？出于可靠性的考虑，我可以说 SQL Server、Oracle 等都运行在 LAN 而不是 WAN 上吗？

Answer 1

您不会详细了解您的应用程序是什么或您与客户的关系。所以这是我根据过去的经验（特别是一次事件）提供的反馈，并牢记以下几点：

1) 您是一名应用程序开发人员，将产品出售给客户，无论是为您自己的公司还是根据合同（您不是内部开发人员）。

2）您的应用程序使用的是前端背后的基本访问引擎。

3) 您的客户正在使用 MDB 文件向您支付此多用户应用程序的费用，该文件现在存储在多个客户端应用程序正在访问的 Windows 共享上。

4) 您的客户有某种 IT 部门，甚至对数据库的熟悉程度最低，如果没有，他们会很快掌握。

5）您的客户唯一的问题是您的应用程序通过此 WAN 链接（即，体面的带宽，大部分可靠，在大多数情况下以稳定的方式适用于其他应用程序。）

这就是我来自的地方。我们有一家供应商向我们出售了一种多用户产品，该产品似乎是随机地定期更新中央服务器上的数据库失败。我负责我们的组织与供应商合作解决问题，因为当失败时我们有几个不开心的人受到影响，而我们的用户在诉诸纸质跟踪方法之前几乎没有耐心找借口。

供应商坚持认为该应用程序在其他（类似）组织中运行良好，因此问题出在我们的网络或系统上。我们更换了系统。他们坚持在附近的房间里放一个迷你交换机来帮助“隔离”流量，因为我们的网络流量太高，导致延迟问题（即使只有他们的应用程序有问题，没有其他明显的延迟问题迹象。 ) 然后他们指责电源，坚持我们将 UPS 放在工作站和他们的迷你开关上以调节电源。每次随机故障都会再次出现。

我们经历了开发人员坚持要修复的每一个环节，只是为了向他们展示不，这不是问题。这个问题相当明显。谷歌对错误消息进行了两分钟的搜索，显示这是一个文件锁定问题，对其应用程序的快速剖析显示它使用的是 MDB 数据库；基本上，该应用程序是 Access 引擎的前端。文件共享上的 MDB 文件根本不适合多用户访问。当有足够多的事务在飞行时，最终我们的两个客户端工作站会在数据库应用程序无法正确锁定要更新的记录的点上命中，并且会出错。

我不是程序员，也不是数据库管理员，这只是我在研究中发现的，我得到了很多人的同意。这种情况在最近的版本中是否有所改变？我不知道。但我确实知道我发现很多人只是说他们做错了。“当您在一个数据库上有多个客户端时，请使用旨在处理多用户访问的网络数据库解决方案。” 祖母可以保留她的曲奇食谱。不太适合通过网络同时处理 20 个需要事务完整性的用户。

现在根据您的情况...在与该供应商打交道时，我可以说当供应商坚持客户是错误的，尽管有其他文档（网络很好，带宽很好，您的应用程序是唯一失败的东西，错误本身就表明您的设计存在缺陷......）他们对您没有耐心让他们跳过箍向您证明他们的网络对于除您的应用程序之外的所有内容都足够可靠。我们的供应商最终所做的只是让自己看起来很愚蠢；在厌倦了与他们一起玩弄之后，我们放弃了他们作为竞争对手，他们甚至拒绝承认错误是他们的应用程序的错误的可能性。

我们跳过了他们希望我们跳过的每个箍，但仍然基本上说这是我们的错，我们无能。无论供应商是否认为我们不称职，告诉签署采购订单的人他们不称职通常都是不明智的，更不用说立即驳回他们自己对问题的发现了。

其次，基于文件的数据库基本上依靠其他机制来帮助在事务中保护它。真正的数据库管理员可能会在这里纠正我，但当时，据我所知，服务器上的多个客户端通过网络访问的这个数据库正在处理文件系统、抽象文件共享文件系统（Windows 共享）和引擎没有同时为多个用户处理正确的数据库锁定。“真正的”数据库（MySQL、MSSQL、MongoDB 等）可以更好地处理这个问题，因为它们就是为此而生的。Access 非常适合跟踪您的食谱和电影收藏。不要将其用于企业处理销售点或大型服务台数据库。

为什么它在局域网内工作？如果您告诉他们（并且他们有一个机智的 IT 部门）所有数据库都应该在局域网内才能正常工作，他们可能会想知道您对数据库的体验如何，除非您知道，否则您会做出这样的声明事实上，他们正在通过 POTS 线路使用相当于 Hayes 调制解调器的方式设置 WAN。事实很可能是使用 MDB 文件是不稳定且容易出错的。将它保留在 LAN 中可以将您的某些争用问题减少到它似乎（通常）工作的阈值以下。如果他们增加使用该数据库的客户端应用程序的数量，即使在局域网内，您也可能会增加应用程序出现的“随机问题”的数量，

换句话说，告诉他们必须把它放在本地服务器上只会在裂开的伤口上贴上创可贴。如果是文件争用或引擎​​问题，它们仍然会出现随机问题，并且增加客户端数量将在性能上遇到另一堵墙和/或减少应用程序随机故障之间的时间。

更不用说如果他们出于内部已知的原因重组了他们的服务器共享，但您的应用程序需要特殊，出于某种原因需要记录其他内容或以不同方式处理，您的应用程序将不会受到 IT 员工的青睐。如果你想和他们建立良好的关系，为什么要对抗他们？

（另外……如果他们有一个 WAN 连接办公室，你确定远程用户永远不需要使用你的产品吗？或者他们可能会转移人们让一些远程用户使用你的应用程序？那么你将拥有拆分网络问题再次出现。）

最后，真正的解决方案是更改为 MSSQL、MySQL 或其他处理正确多用户访问的“真正”数据库引擎。这将使您的应用程序更具可扩展性、更灵活和更可靠。它将使您的产品和您看起来更好。

一种解决方法是创建一种“代理”应用程序，该应用程序序列化来自客户端的查询，处理它们，然后将响应发送到客户端机器，确保从数据库的角度来看，一切看起来都是在本地处理的。这将是性能和扩展应用程序的瓶颈，这是一个笨拙的解决方法，最终它是一个完全错误的解决方案，但如果你快速编写它并且它有效，你可能会使用它作为你的问题的权宜之计，直到你可以实现适当的数据库迁移。如果管理员有我提到的那半个机智，他们可能会严重质疑您的数据库体验，但他们至少会知道您正在为可行的解决方案制定正确的迁移路径。

也许您客户端的 WAN 连接不可靠。也许还有一些其他问题将数据库文件移动到本地网络系统会有所改善。也许我完全不了解您的应用程序的设计方式。但是，如果您的应用程序中的任何内容与我们所处的情况类似，则您的应用程序需要重新设计。如果您在数据库和应用程序之间有适当的抽象，那么更换数据库引擎应该不是一项艰巨的任务，应该会产生巨大的好处。他们的竞争对手基于 MS SQL Express。没问题。我什至不确定我们遇到问题的原始供应商是否仍在营业，尽管他们坚持认为他们有许多满意的客户，他们的产品没有问题。也许这是他们撒谎的另一件事......

但我真的认为你问错了问题。不应该是如何说服客户解决应用程序设计中的潜在缺陷，而是如何与客户解决问题并说服他们在您为他们实施适当的解决方案时坚持使用您的产品问题？这就是我的经验。这是免费的。随便拿吧。