又是一個不用寫代碼的Kata，不過這個Kata確實需要仔細思考一下才能得出結論。
在項目中我們常和數據庫打交道，項目規模越來越大之后，和數據庫的交互就變成了一個獨立的研究領域，也有對應的開發人員和維護人員。對于開發人員來說通常不會直接讀寫數據庫，而是把具體工作交給ORM層。這種模式對開發者個人來說雖然能提高一些開發效率并且屏蔽掉一些關聯度不高的知識點，但是客觀來說是阻礙開發者技術進步的一道屏障。
我是一個Python愛好者，最初寫網站的時候用的是Django，雖然Django也有ORM，但是由于我是獨立開發網站，整個服務器的配置都需要自己完成，所以對于數據庫的配置和操作比較了解。如果大家也想深入了解一下ORM背后是什么，可以自己動手配置一下服務器，同時手動做一些數據庫初始化以及查詢、調試工作，這樣下來應該就可以初步了解數據庫了。
跑題了。
在具體操作數據庫的時候通常有兩種方式，第一種以業務中已經定義的類為單位來獲取數據，第二種以數據表中的行為單位來獲取數據，分別稱為Class方式和Hash方式。
實際使用中，有時候我們無法直接獲取想要的數據，可能需要多表聯合查詢，也可能需要進行一些計算，這時兩種方式的差別就體現出來了。
使用Class方式的話，由于單位是類，需要先獲取實例，然后再處理并得到結果。而Hash方法并沒有類這個中間層，直接讀數據庫并一行一行生成結果。這個Kata的要求就是比較這兩種方法，分析利弊。
比較
在我看來，這兩種方法恰好可以對應IT行業中的大公司和創業公司：大公司做事井井有條非常有序，小公司做事看似混亂但靈活多變。
Class方法的特點是抽象和隔離，具體的處理者無法直接接觸到原始數據，類相當于數據和處理者中間的接口，可以提供數據初步處理、過濾以及屏蔽底層變化這些好處。但是反過來，受限于類本身的行為，處理者能做的事比較有限，做事方法也比較固定，很多時候為了達到目的需要繞遠路。
Hash方法正相反，提供了極大的靈活度，處理者完全可以根據自己的需要來處理數據，但是反過來卻無法保證隔離性，處理者往往要做許多額外的工作來處理數據。
方法沒有好壞，關鍵看場景，言盡于此。
