有了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項目的一個理想選擇。