MySQL非常適合於支持網站內的客戶資源管理（customer resource management，CRM）系統。它已經是很多Web網站不可分割的一部分了，而且其價格水平也是無人能敵的。此外在動態網站裡，很可能已經存在相當數量的CRM數據有待發掘。
在做一家電話公司SAP實施組管理員的過程中，我逐漸精通了其卓越的CRM工具包。我了解到CRM中大約有90%的工作是系統配置實施和維護，以滿足用戶不斷變化的要求。一名CRM的開發人員必須精通過程和結構的設計。現在就讓我們來討論一下，你在使用MySQL創建一個可升級的高性能CRM系統時所要經歷的過程。
為MySQL設計CRM解決方案
CRM數據庫很復雜：你的用戶表格會鏈接到你的聯系方法表格上，後者又鏈接到你的地址和機構的表格上，這兩個表格又鏈接到你的事物表格上，而這個事物表格又鏈接到你的目錄表格上，等等。對於某些關系，你需要創建復雜的復合索引。對於其他的關系，你可能只需要簡單的索引，或者根本就不需要。你實現裡的更新和刪除可能會也可能不會被層疊。
這就意味著，你需要極其熟悉MySQL裡可用的調整方法。但是在你能夠進行調整之前，你就需要設計一個CRM過程，依靠它來利用這些調整方法。
邏輯和數據流
正如你能夠在圖A裡看到的那樣，你可以將MyISAM表格作為報告類型數據的源來使用。這非常有用，因為在你只是簡單地查詢數據庫時，ISAM表格將是個閃電般快速的數據源。ISAM的缺點是，表格文件自身可能會崩潰，而對其數據的更新很容易就會導致這樣的問題。
圖A
要解決ISAM的不穩定性，你可以使用InnoDB表格來添加、更新和刪除數據表格裡的記錄。InnoDB引擎是事務性（transactional），所以如果更新失敗，那麼數據就會退回到更改之前的狀態。InnoDB在參照上更加完整，這樣數據的更新就不會違反表格之間的任何關系法則。
上面的圖表中所沒有反映出來的東西是，你應該隨時備份你的數據。在這樣的情況下，ISAM表格裡所保存的都是貴重的數據。這些表格都是你應該備份的東西。你可以在InnoDB表格裡獲得同樣的數據，但是ISAM的表格更適合於備份過程的查詢。
對InnoDB表格的恢復操作也是出於同樣的原因——它們更適合於更新（例如參照的完整性、速度、穩定性等等），而且它們將被自動地與任何有待添加／更新的操作進行同步。如果InnoDB表格不幸崩潰了，那麼就能夠利用ISAM的數據來重建表格，這就是為什麼要將這個過程像這樣分割的最好原因了。畢竟，冗余就等於安全。
要注意，在圖A裡連接表格A和表格B的線條顯示其是一個單向的同步過程。它涉及報告（Report）表格（表格A、ISAM）的鎖定，然後將更新（Update）表格（表格B、InnoDB）推回給表格A。這一過程發生得很快，因為在這一點上不會有或者很少會有數據的確認。MyISAM在設計上就不支持它。
當然，不是所有的CRM都是設計用來和MySQL一起工作的。它們通常都會支持MySQL，但是它們沒有利用到其特有的性能和設計特性。例如SAP、PeopleSoft以及微軟CRM都沒有為MySQL提供任何優化的特性。這就是為什麼它們都是根據甲骨文和微軟的RDBMS設計范例所創建的原因了。
還是有很多CRM工具包都是圍繞LAMP（Linux／apache／MySQL／PHP）這一基礎來設計的。這些通常都是開放源代碼的項目，與之相關的好處以及花費是可想而知的。由於CRM幾乎總是涉及很多軟件的自定義以及商業過程的分析，所以它相當樂意參與到開放源代碼的開發工作中來。開放源代碼所提供的設計更新間隔正是系統同企業實際操作進行同步所需要的，至少是在盡可能地同步。
用於MySQL的幾種CRM工具包
下面這些CRM工具包已經為同MySQL一起使用進行了優化：
獨特的設計范例
如果你正在參與使用MySQL創建CRM解決方案的工作，那麼你就需要將技術同商業技巧有效地結合起來。將系統裡的接口同真實世界裡的接口相匹配，需要你對MySQL獨特設計范例裡可用的性能增強特性有一個深入的了解。理解MySQL的事物以及非事物表格類型將是理解這個范例的關鍵，但是諸如索引和關鍵字的合成（key composition）也有其作用。
MySQL能夠被用作常用的大型CRM工具包的後端數據庫，但是這些工具包往往不能夠利用MySQL的優化特性以及設計范例。但是，很多開放源代碼的工具包的確利用了MySQL特有的特性，或者它們能夠在源代碼這一層次被調整以利用這些特性。這就讓MySQL成為了你CRM項目的一個理想選擇。
