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的數據來重建表格，這就是為什麼要將這個過程像這樣分割的最好原因了。畢竟，冗余就等於安全。
