很多MySQL用户都有过将Access移植到MySQL的计划，不过这个移植过程性能和实践的相关描述资料很少。本文将为大家总结将Access应用程序成功移植到MySQL的要点和注意事项。

　　由于Access应用程序往往是以即席(ad hoc)模式创建的，移植难度很大。MySQL用户通常会遇到的两个移植问题是：第一，数据移植问题，由于Access模式设计较差，数据质量很低，往往会造成数据转换过程很复杂;第二，应用程序移植问题，Access应用程序中的窗体和报表常包含了逻辑或设计错误，不可能实现这些文件的自动转换。

　　成功的移植途径要完成以下三个基本任务：重构模式、清洗数据和重写应用程序。

　　从Access到MySQL的移植动因

　　Access数据库由于其操作简单易用，成本较低在中小企业中的市场非常广阔。中等技术程度的部门开发人员都会把Access作为数据库开发的默认选择。大家往往通过将企业数据下载到Excel里，然后将电子表格转换成Access数据库，然后添加即席窗体和报表来构建Access应用程序。由于这些程序由用户组织构建的，所以往往缺乏对数据形式的要求。

　　在Access应用软件移植上，MySQL用户面临的压力越来越大，包括以下几个方面：

• 　　数据质量低下：Access应用程序常常包含了过期的企业数据或来自拙劣定义模式下的损坏数据;
• 　　安全性能低下：Access应用程序没有嵌入企业安全组件，不允许进行类似于基于角色的访问控制等的高级安全设置;
• 　　可管理性有限：网络技术无法集中管理Access应用程序;
• 　　沒有基于网络发布机制：Access应用程序无法通过网络进行访问;
• 　　不符合SOX依从性：企业的审核程序往往会把Access应用程序看作是一个重要的风险来源。

　　数据移植问题

　　MySQL本身提供了一个数据移植工具—— MySQL Migration Tool。不过这个工具实际上和待转换的数据库的基本模式和数据一样并不好用。而Access的模式和数据质量问题太过深入且普遍存在，所以MySQL用户常常会发现在MySQL从头开始重建数据模式还有来得更容易些。

　　Access移植过程中最两个常见的与数据质量相关的问题是：

　　1. Access数据模式不是基于SQL的模式：Access开发人员往往不熟悉SQL模式设计基础。MySQL的数据库管理员会发现，Access模式类似于Excel的电子表格，而和典型的SQL模式相去甚远。例如，这种模式缺乏主键、外键和参照完整性约束。

　　2. Access数据“不干净”：Access数据库中往往包含很多毁坏的数据，其中部分原因是由于没有对表进行严格定义。有MySQL用户曾经发现在一个Access数据库中，在本来应该是日期字段的区域填入的却是文本字符串。

　　应用程序移植问题

　　成功把数据从Access接入到MySQL仅仅解决了一部分问题，还需要处理与Access应用程序相关的窗体和报表问题。此外，你可以把多个Access应用整合成一个web应用;同样的，还可以把多个Access窗体整合成一个网页。虽然可以用ODBC从Access存取MySQL数据，不过大多数MySQL用户还是选择重新编写应用程序。其中的原因包括：

• 　　质量问题：鉴于原始的Access应用程序不是由专业的编程人员写的，MySQL用户对其逻辑可行性往往持有怀疑态度。
• 　　想要是应用程序适用于网络：大多数MySQL用户都想把Access应用程序转换成动态的网络架构。
• 　　出于安全要求：MySQL用户往往希望为程序加入企业级的安全特性，例如Siteminder/LDAP验证和基于角色的访问控制机制等。

　　虽然有现成的工具可以将Access应用程序自动转换成Java，不过大部分MySQL用户发现自动转换的成功率很低。一条可行的途径是使用类似于PHP的编程语言或ActiveGrid这样的web 2.0 visual builder来接入Access应用程序。

　　MySQL快速应用开发工具

　　由于将Access应用程序移植到MySQL的过程往往需要重新构建应用程序，MySQL用户能够加速应用程序开发过程的工具会非常感兴趣。

　　作为Web2.0 架构的可视化开发平台，ActiveGrid系统能够为MySQL用户大大简化Access应用程序移植的任务。很多Access应用程序开发人员(对于急于完成移植任务的MySQL数据库管理员来说也是如此)更希望用一个可视化方式来构建应用程序，而对复杂的Java架构兴趣索然。对这些开发人员来说ActiveGrid应该是个不错的选择。

　　根据模型-视图-控制器(MVC)的三步设计模式可以助你轻松构建一个ActiveGrid应用程序：

　　1. 定义模型：模型用来定义应用程序中的数据，包括数据库表和表之间的关系，即对象的属性。开发者通过输入一个现有数据库模式或使用可视化数据编辑器来详细指明这些信息。

　　2. 创建视图：视图用来描述应用程序所显示的网页，是模型的外在表现形式。ActiveGrid能够根据数据库模式创建默认的Ajax网页，此外，开发者可以用可视化屏幕生成器来创建全新的网页。

　　3. 构建控制器：控制器用来管理应用程序内部的各种操作，包括页面之间的导航、数据的调用、安全问题和网络服务。开发者可以使用可视化操作编辑器来定义新的操作，编辑器可以调用网络服务，也可以调用以Java或Python编写的自定义代码模块。

　　移植Access的流程

　　MySQL用户都知道Access的自动转换工具在移植过程中往往用处不大。例如，能够将现有的Access应用程序转变为Java模式的工具，往往只能进行到八成，要想完成剩下的两成任务，需要花费的时间比从头开始编写程序还要长。

　　所以，移植Access的最佳方法是重新构建模式、清洗数据、然后重写应用程序。虽然这样做时间要求很紧迫，但这是唯一能保证出来的应用程序质量过关并能够实现日后维护的方法。

　　从Access到MySQL的移植过程最好能够按照以下的步骤循序渐进的进行：

　　1. 重新构建模式：在MySQL中创建一个新模式，要能够反映SQL的最佳实践，而不是简单地在MySQL中重新创建Access模式。必须确保对以下的元素进行合适定义：1)主键;2)用于一般查询和列连接的索引;3)外键，用于表数据之间的关联，以及基数约束和删除约束传播;4)列的缺省值;5)允许填入空值的列;6)视图。

　　2. 清洗数据：使用MySQL移植工具或简单的.CSV导出文件从Access数据库中抽取数据，先对数据进行以下的清洗操作，然后导入到新的MySQL模式中：1)确保主键唯一性;2)确保参照完整性——检查对所有外键来说有主键存在，保证外键的一一对应关系;3)确保非空列都写入了值;4)确保数据类型的一致，特别是日期、整数和小数数据类型;5)将清洗过的数据导入到新的MySQL模式中。

　　3. 重写应用程序：重新检查一遍窗体、报表和查询等Access应用程序，然后利用网络开发工具重新设计窗体和报表应用程序，不要试图转换现有的应用程序和脚本：1)将MySQL数据模式导入到ActiveGrid的可视化编辑工具中;2)使用网页编辑器为应用程序创建带有图形界面的新网页;3)使用操作编辑器或自定义Java/Python代码或网络服务为应用程序定义实现功能所必须的操作。

　　总结

　　综上所述，很多企业为了提高安全性能和部门应用程序的数据质量，逐渐从Access转向使用MySQL数据库，将Access移植到MySQL，需要我们小心的将数据转移到一个新的模式，并利用基于网络的开发工具重新构建应用程序的窗体和报表。