随着越来越多的公司涉足开源业务系统，许多公司正在构建从 Web 到后端的堆栈，这些堆栈通常包括 Linux、PHP、Apache Web 服务器和开源数据库，通常是 MySQL 或 PostgreSQL。PostgreSQL 近来在许多方面越来越受欢迎，有人说，它已经达到了功能和稳定性的临界质量。包括 Red Hat 在内的几家知名公司现在提供 24/7 全天候支持。本文介绍了从 Microsoft Access 切换到开源数据库（在本例中为 BSD 许可的 PostgreSQL）时的预期情况。

Bike Friday 公司的信息系统经理 Michael Calabrese 最近接受了这一挑战。Bike Friday 是一家快速扩张的旅行和山地自行车公司，总部位于俄勒冈州尤金市。它使用 PostgreSQL 来处理其所有销售、制造和客户支持数据。Calabrese 还正在将公司所有的电子商务系统从专有系统更改为开源系统——Linux 和 Apache，核心是 PostgreSQL。不过，目前，他保留了 Microsoft Access 97 作为前端，以便在用 PostgreSQL 替换后端并添加新功能的同时，最大限度地减少停机时间。Calabrese 说

Calabrese 决定迁移到 PostgreSQL，因为它是一个更具企业级能力的系统。它具有成熟的事务管理系统，带有一个称为多版本并发控制 (MVCC) 的复杂数据锁定机制，即使数据正在使用中，也允许只读访问数据。

将 Microsoft 开放数据库连接 (ODBC) 驱动程序加载到 PostgreSQL 模板数据库中，使 Access 和 PostgreSQL 可以协同工作。除了基本的转换工具（请参阅“资源”）外，Access 有时需要运行的其他 ODBC 服务器端函数 psql <数据库名称> <odbc.sql> 位于目录 src/interfaces/odbc/odbc.sql 中。PostgreSQL 还提供了一个平台独立的 Type 4 Java 数据库连接接口 (JDBC) 驱动程序。C (ECPG) 的嵌入式接口也是 PostgreSQL 的一部分。安装完成后，Calabrese 选择了数据迁移工具，如 pgAccess（有 Windows 和 UNIX 版本）和 exSQL 公共版本 3.1。

在使用包含的工具（pg_dumpall 实用程序或 pg_dump 和 pg_dumpaccounts 实用程序的组合）备份现有数据库并运行安装程序后，数据转换的第一步是查找 Access 中的非法文件名。Access 在允许其他数据库（包括 Oracle、Sybase 和 PostgreSQL）无法理解的非法字符方面非常宽松。因此，Bike Friday 的运输和订购数据中，Access 认为可以的许多非法术语必须为 PostgreSQL 进行转换。例如，像 Order Detail 这样的表需要变成 Order_Detail 或 OrderDetail，而像 Shipped? 这样的字段名称必须变成 Shipped 或 ShippedYN。

基本转换工具将自动删除所有非法字符。对于那些使用现有前端的人来说，这可能会有问题，因为前端和后端可能会在没有明显原因的情况下停止通信。Calabrese 建议任何计划保留现有前端的人都不应更改前端数据中包含非法字符的名称，或者手动进行并行更改。在他的情况下，Calabrese 发现自己手动逐个更改 Bike Friday 前端和后端上的字符，这没问题，因为无论如何他都必须更改前端。无论哪种方式，都应该在此时执行许多测试中的第一个测试，以确保一切正常。解决非法字符问题后，数据就可以进行转换了。

对于那些计划在转换后的后端之上运行 Access 前端的人来说，pgAdmin 应该能够充分胜任自动移动数据的工作。Calabrese 还使用了修改后的 exSQL 版本来定义 Access 和 PostgreSQL 将如何处理表之间的关系。他在 www.geocities.com/musica_6898/ postgresaccess_home.html 上公开的版本运行一个脚本，该脚本更改了多个任务的字段类型转换，例如 регулирование Access 如何处理货币类型。Bike Friday 的 Access 前端将 PostgreSQL 的数字十进制字段视为文本字段。为了使 Access 正确查看数学运算，Calabrese 将字段更改为 Float4——PostgreSQL 用来描述四字节浮点数的方法——允许 Access 正确读取它们。

Bike Friday 的界面有 100 多个表，相当复杂。从用户端来看，Bike Friday 使用 80 多个屏幕来完成从输入订单、查看零件表到安排生产和跟踪库存的所有事情。因此，Calabrese 必须确保系统可以为数十个用户扩展。测试花费了数周时间，在此过程中根据需要重新设计 SQL 查询，或者通过在 Access 端重写它们，或者在证明有问题时，在后端重写它们，直到它们以快速运行为止。清单 1 和清单 2 说明了典型查询和为速度优化的查询之间的差异。

清单 1. 效率相对较低的查询

清单 2. 为速度优化的相同查询

通常，人们使用 SQL 命令（如 Create index、vacuum、vacuum analyze、cluster 和 explain）来优化 PostgreSQL 查询。但是，Calabrese 提出了这个警告：Access 97 擅自根据它认为更有效的方式更改了他的查询。Calabrese 通过使用传递查询来阻止这种情况，该查询告诉 Access 不要触及查询，而是将其直接发送到后端。

在为 Bike Friday 的 PostgreSQL 数据库进行的优化中，Calabrese 通过提取更小、更精确的数据量获得了大部分速度提升。他告诉数据库仅查看使用大约 2,000 个详细信息的订单，而不是数据库一次查询 100,000 个产品订单详细信息。“Access 很贪婪”，Calabrese 说。“它每次都会抓取所有记录并遍历它们。这非常低效。我们公司现在有 30 个人，如果每个人都有一台计算机访问数据库，那么在速度方面就会很快成为问题。”

更改的下一阶段是调试查询，这里有两条基本途径。第一种是激活和使用 PostgreSQL 的 ODBC 驱动程序中的调试工具。可以使驱动程序创建一个日志，以便每当 Access 发送 SQL 命令时，PostgreSQL 都会将其放入日志中，该日志写入 C 盘的根目录。如果 Access 尝试检索像 100,000 行这样的内容，或者以其他方式破坏查询，例如，将其分解为一千个较小的查询，这将当场抓住 Access。基本上，这是一个审计跟踪，可以更容易地捕获异常查询并在出现问题时重写它们，就像这里的情况一样

conn=86311032, query=' '
CONN ERROR: func=SQLDriverConnect,
desc='Error from CC_Connect',
errnum=105, errmsg='The database does not exist
on the server or user authentication failed.'

或者，如果 Access 发送查询并且系统挂起，则可以更改服务器端的调试级别以读取发送给它的查询。微调是通过遍历每个屏幕并测试它们来确保它们都达到速度，方法是简化查询、使其更快或组合它们。考虑到一些 SQL 知识可能有多么深奥，这个过程听起来容易，但实际上并非如此。但是，此时运行两到三个完整的 alpha 测试将为以后节省麻烦。

在将整个系统投入生产之前的下一步是进行 beta 测试。Calabrese 在销售人员、主管和同事实时使用 Bike Friday 的后端系统时对其进行了监控。“您不仅要测试前端是否有错误，还要测试您需要将服务器做多大”，Calabrese 说。他编写了一个查询脚本，密切关注三个主要瓶颈（CPU、磁盘和网络），以查看它们正在承受什么负载。

对于硬件调整（CPU、磁盘和内存），Bruce Momjian 在 Linux Journal 上的文章“PostgreSQL 性能调优”（2001 年 8 月刊，也可在线访问 www.linuxjournal.com/lj-issues/issue88/4791.html）提供了一个方便的概述。Calabrese 的脚本根据负载保持在 100%、50% 和空闲状态的秒数来衡量 CPU 压力。它从磁盘的读取和写入次数以及这些读取和写入的千字节数方面查看磁盘传输。至于网络速率，Calabrese 的脚本计算每秒的数据包数和每秒的字节数。Calabrese 还建议在隔离网络上执行 ping/F，这是一种 flood ping，它将指示服务器在达到最大值之前可以承受多少负载。就内存而言，您拥有的内存越多，PostgreSQL 将加载到其中的数据就越多，数据库的速度就越快。

当然，真正确定数据库是否足够快的唯一方法是使用它的人是否觉得它足够快。在纸面上看起来微不足道的零星等待在实际时间中可能会长得多。每个组织对速度和性能都有自己的容忍度。确保数据库以组织希望的方式工作的唯一方法是让人们使用它并听取他们的意见。

最后，一旦您完成了一些生产测试，列出并清理了界面中的所有错误，您就可以为真实的、企业级的电子商务推出开源基础架构了。

资源