在相當多的地方聽到了「池」的概念，如「專案池」、「獎金池」；雖然感覺上很熟悉，但是在業務角度，「池」的概念相對來說還是比較抽象的；
一般，「池」的理解可以是一大堆事務的集散地，這種「池」可以根據這些放置的主要事務來命名，如「專案池」主要放置的各種專案，當然，在不同行業，專案又會有不同的概念，這是毋庸置疑的。
「池」一般首先想到的就是對於「查詢」的要求，這是很普遍也是很基本的要求。這也就要求在進行系統設計，或者說是「池」的設計時，進行相應的細節考慮。「如何能快速的從池中找到並查詢出我想要的？」這是使用者最為關心的，也是技術要求上最為複雜與困難的，也許一般的認為就是乙個簡單的查詢，但是，在實際許多的專案、系統開發中，真正體現價值的往往一開始便是查詢功能的體現；
在「池」的使用過程中，基本的分類一定是要有的，不能隨便把任何的東西放入「池」中，這和現實生活中的池塘的概念在某種程度上還是有相似性的。在系統設計中是可以允許有多個、多種型別的「池」出現的。那麼相應的在資料庫的設計上就需要更多的考慮，包括外掛程式、前端等技術的使用考慮，甚至也會衍生出成本的核算。一般對於生產型的系統，如「xx管理系統」，對於有流程、控制等需求時，很多越做越大後，就會發現，如果不能將這些管理源進行相應的「池」化，否則會對程式的維護造成很大的影響，相應的也就會影響到使用者體驗上；
「池」可以是虛擬的，這種池一般就存在程式中，如「資料庫連線池」、「執行緒池」，這種池的概念不同於其他的「池」，這種型別的「池」多對於程式，或者硬體、網路等因素有約束；而且，這種池的設計可以相當的靈活，並且在一定程度上是可以進行互轉或者共用等等，不過對這種「池」的優化有時候也會成為基本技術要求中的難點；
「池」是有基點的，並不是任何東西都能夠形成「池」，水多了並不能形成「池」，因為「池」包含的意義或者事務一旦都單一或者相同，則很容易分辨與篩選出來，那麼就不需要「池」了，但是這種情況和我前面所提到的有所不同。前面對於型別的概念與對於我現在講述的基點是不同的，基點更多的是強調在數量的體現，這有點像「江」、「河」、「湖」的概念吧。同時基點是不同變化的，並一直會隨時間的變化而不斷變化。有時候甚至會在某個時候這個「池」會變為一種「消失」狀態，相當於我們在做程式的時候的「修改」與「刪除」的概念。當「池」的基點變低時，並不意味這「池」就一定會消失，而往往這個時候的「池」會形成另外乙個新「池」，這種「池」主要儲存的是在基點變化過程中的歷史的「記錄」，這時候相對與大型企業來說，這就是「追本溯源」，這就是「總結」。這種「池」往往比前面時段的「池」更具價值，這時，「池」便可以選擇轉化為新「池」，或者繼續使用，直接進行抽取，但後者的情況一般較難發生，因為，大多數的池在形成這種狀態的時候很多資料都已經不能靈活了，在不能改變舊資料的情況下去修改系統設計是很冒險的，也是很激進的。一般的企業會選擇前者，成立乙個新「池」，只是「換湯不換藥」，從另外的用途或者角度來使用，也可以說這便是「池」的「轉型」吧。
說到「池」的成立，就一定會涉及到「池」的回歸。回歸其實真正意義上多是資料的重組與回歸。例如「獎金池」便是不斷資料重組與回歸的，這種池要求的是池內總體金額的穩定性，從某個方面也正體現了企業獎金制度的穩定性與完善，獎金的發放需要補充，從某種意義上獎金池的資料初始**便是員工的剩餘價值。也有某些資料回歸會是很雜亂無章的，這時也會有部分的整理工作，這倒是額外的工作了。「池」的回歸保證的是「池」內事務的完整性與「池」的運轉，從某種程式上這便是企業的運轉，但這也要取決於「池」的大小與企業的制度，理念了。
「池」不管是虛擬的，還是只是乙個設計思路或者概念，在一定程度上，不僅在反映企業的業務邏輯，同時也是我們程式的後台設計圖紙，「池」設計得好，那麼整個系統在運作起來便很有一定的邏輯，程式體現的是邏輯，或者是業務。當然，無論多麼複雜的去設計，修改，維護工作是一定不能少的。而我們需要做的，不管是從一開始的「池」的成立，到「池」的維護，到「池」的回歸，都需要仔細的去審核，仔細的思考。
msn ：
Nsis的自我理解
nsis 指令碼語言的理解 1.nsis 語言的理解 nsis指令碼語言比較獨特，類似於巨集彙編，語法有些像c語言，感覺是純面向過程的東東。功能還算強大，能呼叫windows api，支援用動態鏈結庫形式的擴充套件。能呼叫和建立核心物件。例如可用用createmuteex 用來建立單例項。此處深有體...
AngularJS的自我理解
最近在學angularjs的框架開發，雖說到現在還只學到一半，但是我還是想把從開始到現在對angularjs的思路理解寫下，以便更好的回顧所學的知識。當然 後續的學習我也會在後面完善這一半的結果。以下是我自己最近所學的理解，當然理解走向有誤也希望有讀者能夠指出，菜雞在這裡先謝謝了！angularjs...
this物件的自我理解
函式中的this是存在，就看這個this被繫結到哪個物件了 當乙個函式用作建構函式時 使用new關鍵字 它的this被繫結到正在構造的新物件。建構函式這樣工作 function myconstructor function c var o new c var t new c console.log ...