在做完了之前的一系列工作之后，終于要進行應用后臺的設計和實現環節了。在后臺設計中，我們覺得數據庫的設計是最重要的根基，因為所有業務邏輯均是架構在數據庫的基礎之止，如果對數據庫進行修改，程序可能需要大改，工作量將非常之大，所以數據庫設計必須非常重視。
在談數據庫設計之前，我們先談一下ORM，即關系數據庫與html' target='_blank'>面向對象系統的映射，其理由是面向對象開發人員，不了解關系型數據庫，因些引入ORM，使其不需要學習關系型數據庫就可以進行數據庫開發。我們認為，關系型數據已經有了幾十年的發展歷史，理論和實踐都很成熟，反觀ORM發展不過十來年左右，理論、功能和性能方面，都有很多問題，雖然在當前大行其道，但是我們認為其引入的問題，遠比所解決的問題要多。我們認為，如果一個面向對象程序員，如果學習關系型數據庫覺得有困難，那么不是這種技術不好，而是他可能根本不適合編程。因此我們倡導直接采用關系型數據庫技術，不采用任何ORM框架。
回到數據庫設計的話題，說到數據庫設計，其理論基礎是范式，尤其是第二和第三范式，是數據庫設計的基礎，我們必須對這些范式非常熟悉。當然，因為在其際項目中，由于性能方面的考慮，可能會違反范式，引入數據冗余，但是理解和掌握范式，對于我們設計出合理的數據庫邏輯模型還是非常有幫助的。
關于數據庫設計范式的詳細內容，大家可對考百度百科的詞條（百度百科數據庫范式）。這里就不再討論了。
我們這里討論的是用戶注冊，看似用戶數據庫設計很簡單，但是在實際應用中，卻是一個比較復雜的問題。比如，在移動醫療應用中，我們應用的用戶比如說是張三，他直接作為患者是一種簡單的情況，但是他可能要替他的父母和孩子掛號看病，這時張三還是用戶，但是實際接受服務的主體是他的父母和孩子，這需要怎么表示呢？還不僅如此，到醫院就診還需要就診卡，而通常情況下，一個人可能有多張就診卡，醫院是只認就診卡的，怎么將就診卡對應到真實患者呢？再有，有些醫院有會員系統，用戶可以給會員卡充值，從而享受優惠，張三的會員卡，可以同時給父母和孩子使用，這種情況又如何表示呢？
以上分析的還僅僅是醫療方面的應用，在其他方面的應用，同樣存在這樣的問題，例如社區O2O中，社區便利店，實際服務的是某個房間，可能與業主是無關，同時，業主可能同時有幾套房，O2O運營商怎么識別出該業主同時有幾套房需要服務的信息，或者是業主全家遷移到新的住處，按照其以往的消費習慣，直接配送其所需的產品和服務。
上面所講的應用場景，都需要在用戶數據庫設計中加以考慮。為了討論問題方便，這里以移動醫療的用戶數據庫設計為例，討論如何設計出更好的數據庫結構，以滿足實際應用的需要。
我們先對用戶進行分類，明確以下幾個概念：用戶是直接使用我們產品的人，在上面的例子中，就是張三；客戶是為產品和服務付費的實體，可以是張三綁定了會員卡；消費者是享受我們產品和服務的人，如果張三替父母或孩子咨詢問題，那么張三的父母和孩子就是消費者，消費者是一個通用的概念，在這里就是患者。
如上圖所示，用戶只保存用戶登錄所需要的基本信息，這里需要注意的一點，雖然很多應用都是用手機號登錄，但是千萬不要把手機號作為登錄名，因為用戶手機號可能改變，所以用專門的手機號來存儲比較合理，可以取登錄名初始時與手機號一致。
系統的會員卡用賬戶來表示，一個會員卡代表一個賬戶，用戶綁定一個賬戶后，就變成了客戶，客戶是用于付款的實體。
張三、張三的父母和孩子都是消費者，對應于consumer表中的一條記錄，當用戶登錄后，會自動綁定自己缺省的consumer。當張三想要給自己的父母咨詢時，其可以綁定父母的consumer，然后進行咨詢，這時與醫生聊天時，就會顯示張三父母的頭像，點擊頭像就可以顯示張三父母的病歷。系統記錄本次咨詢記錄時，記錄user_consumer_id作為咨詢者信息，如果醫生想要聯系患者，可以通過這條記錄，找到用戶，然后通過用戶信息，聯系到患者。如果聯系不上的話，還可以查看該consumer下還有哪些用戶，然后依次與這些用戶聯系，達到最終聯系患者的目的。
華麗的分隔線
******************************************************************************************************************************************************************************
希望大家多支持，有大家的支持，我才能走得更遠，謝謝！
銀行賬號：622202 0200 1078 56128 閆濤
我的支付寶：yt7589@hotmail.com
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
新聞熱點
疑難解答
