有了MySQL，客户资源管理尽在掌握[图]_MySQL

MySQL非常适合于支持网站内的客户资源管理（customer resource management，CRM）系统。它已经是很多Web网站不可分割的一部分了，而且其价格水平也是无人能敌的。此外在动态网站里，很可能已经存在相当数量的CRM数据有待发掘。

在做一家电话公司SAP实施组管理员的过程中，我逐渐精通了其卓越的CRM工具包。我了解到CRM中大约有90%的工作是系统配置实施和维护，以满足用户不断变化的要求。一名CRM的开发人员必须精通过程和结构的设计。现在就让我们来讨论一下，你在使用MySQL创建一个可升级的高性能CRM系统时所要经历的过程。

为MySQL设计CRM解决方案

CRM数据库很复杂：你的用户表格会链接到你的联系方法表格上，后者又链接到你的地址和机构的表格上，这两个表格又链接到你的事物表格上，而这个事物表格又链接到你的目录表格上，等等。对于某些关系，你需要创建复杂的复合索引。对于其他的关系，你可能只需要简单的索引，或者根本就不需要。你实现里的更新和删除可能会也可能不会被层叠。

这就意味着，你需要极其熟悉MySQL里可用的调整方法。但是在你能够进行调整之前，你就需要设计一个CRM过程，依靠它来利用这些调整方法。

逻辑和数据流

正如你能够在图A里看到的那样，你可以将MyISAM表格作为报告类型数据的源来使用。这非常有用，因为在你只是简单地查询数据库时，ISAM表格将是个闪电般快速的数据源。ISAM的缺点是，表格文件自身可能会崩溃，而对其数据的更新很容易就会导致这样的问题。

图A

CRM设计的数据流

 

要解决ISAM的不稳定性，你可以使用InnoDB表格来添加、更新和删除数据表格里的记录。InnoDB引擎是事务性（transactional），所以如果更新失败，那么数据就会退回到更改之前的状态。InnoDB在参照上更加完整，这样数据的更新就不会违反表格之间的任何关系法则。

上面的图表中所没有反映出来的东西是，你应该随时备份你的数据。在这样的情况下，ISAM表格里所保存的都是贵重的数据。这些表格都是你应该备份的东西。你可以在InnoDB表格里获得同样的数据，但是ISAM的表格更适合于备份过程的查询。

对InnoDB表格的恢复操作也是出于同样的原因――它们更适合于更新（例如参照的完整性、速度、稳定性等等），而且它们将被自动地与任何有待添加／更新的操作进行同步。如果InnoDB表格不幸崩溃了，那么就能够利用ISAM的数据来重建表格，这就是为什么要将这个过程像这样分割的最好原因了。毕竟，冗余就等于安全。

要注意，在图A里连接表格A和表格B的线条显示其是一个单向的同步过程。它涉及报告（Report）表格（表格A、ISAM）的锁定，然后将更新（Update）表格（表格B、InnoDB）推回给表格A。这一过程发生得很快，因为在这一点上不会有或者很少会有数据的确认。MyISAM在设计上就不支持它。

收缩包装的CRM

当然，不是所有的CRM都是设计用来和MySQL一起工作的。它们通常都会支持MySQL，但是它们没有利用到其特有的性能和设计特性。例如SAP、PeopleSoft以及微软CRM都没有为MySQL提供任何优化的特性。这就是为什么它们都是根据甲骨文和微软的RDBMS设计范例所创建的原因了。

还是有很多CRM工具包都是围绕LAMP（Linux／Apache／MySQL／PHP）这一基础来设计的。这些通常都是开放源代码的项目，与之相关的好处以及花费是可想而知的。由于CRM几乎总是涉及很多软件的自定义以及商业过程的分析，所以它相当乐意参与到开放源代码的开发工作中来。开放源代码所提供的设计更新间隔正是系统同企业实际操作进行同步所需要的，至少是在尽可能地同步。

用于MySQL的几种CRM工具包
下面这些CRM工具包已经为同MySQL一起使用进行了优化：

Flamingo Internet Navigators OnmiStarLive Anteil
独特的设计范例

如果你正在参与使用MySQL创建CRM解决方案的工作，那么你就需要将技术同商业技巧有效地结合起来。将系统里的接口同真实世界里的接口相匹配，需要你对MySQL独特设计范例里可用的性能增强特性有一个深入的了解。理解MySQL的事物以及非事物表格类型将是理解这个范例的关键，但是诸如索引和关键字的合成（key composition）也有其作用。

MySQL能够被用作常用的大型CRM工具包的后端数据库，但是这些工具包往往不能够利用MySQL的优化特性以及设计范例。但是，很多开放源代码的工具包的确利用了MySQL特有的特性，或者它们能够在源代码这一层次被调整以利用这些特性。这就让MySQL成为了你CRM项目的一个理想选择。