池"概念的自我理解

在相当多的地方听到了“池”的概念，如“项目池”、“奖金池”；虽然感觉上很熟悉，但是在业务角度，“池”的概念相对来说还是比较抽象的；

一般，“池”的理解可以是一大堆事务的集散地，这种“池”可以根据这些放置的主要事务来命名，如“项目池”主要放置的各种项目，当然，在不同行业，项目又会有不同的概念，这是毋庸置疑的。

“池”一般首先想到的就是对于“查询”的要求，这是很普遍也是很基本的要求。这也就要求在进行系统设计，或者说是“池”的设计时，进行相应的细节考虑。“如何能快速的从池中找到并查询出我想要的？”这是使用者最为关心的，也是技术要求上最为复杂与困难的，也许一般的认为就是一个简单的查询，但是，在实际许多的项目、系统开发中，真正体现价值的往往一开始便是查询功能的体现；

在“池”的使用过程中，基本的分类一定是要有的，不能随便把任何的东西放入“池”中，这和现实生活中的池塘的概念在某种程度上还是有相似性的。在系统设计中是可以允许有多个、多种类型的“池”出现的。那么相应的在数据库的设计上就需要更多的考虑，包括插件、前端等技术的使用考虑，甚至也会衍生出成本的核算。一般对于生产型的系统，如“XX管理系统”，对于有流程、控制等需求时，很多越做越大后，就会发现，如果不能将这些管理源进行相应的“池”化，否则会对程序的维护造成很大的影响，相应的也就会影响到用户体验上；

“池”可以是虚拟的，这种池一般就存在程序中，如“数据库连接池”、“线程池”，这种池的概念不同于其他的“池”，这种类型的“池”多对于程序，或者硬件、网络等因素有约束；而且，这种池的设计可以相当的灵活，并且在一定程度上是可以进行互转或者共用等等，不过对这种“池”的优化有时候也会成为基本技术要求中的难点；

“池”是有基点的，并不是任何东西都能够形成“池”，水多了并不能形成“池”，因为“池”包含的意义或者事务一旦都单一或者相同，则很容易分辨与筛选出来，那么就不需要“池”了，但是这种情况和我前面所提到的有所不同。前面对于类型的概念与对于我现在讲述的基点是不同的，基点更多的是强调在数量的体现，这有点像“江”、“河”、“湖”的概念吧。同时基点是不同变化的，并一直会随时间的变化而不断变化。有时候甚至会在某个时候这个“池”会变为一种“消失”状态，相当于我们在做程序的时候的“修改”与“删除”的概念。当“池”的基点变低时，并不意味这“池”就一定会消失，而往往这个时候的“池”会形成另外一个新“池”，这种“池”主要存储的是在基点变化过程中的历史的“记录”，这时候相对与大型企业来说，这就是“追本溯源”，这就是“总结”。这种“池”往往比前面时段的“池”更具价值，这时，“池”便可以选择转化为新“池”，或者继续使用，直接进行抽取，但后者的情况一般较难发生，因为，大多数的池在形成这种状态的时候很多数据都已经不能灵活了，在不能改变旧数据的情况下去修改系统设计是很冒险的，也是很激进的。一般的企业会选择前者，成立一个新“池”，只是“换汤不换药”，从另外的用途或者角度来使用，也可以说这便是“池”的“转型”吧。

说到“池”的成立，就一定会涉及到“池”的回归。回归其实真正意义上多是数据的重组与回归。例如“奖金池”便是不断数据重组与回归的，这种池要求的是池内总体金额的稳定性，从某个方面也正体现了企业奖金制度的稳定性与完善，奖金的发放需要补充，从某种意义上奖金池的数据初始来源便是员工的剩余价值。也有某些数据回归会是很杂乱无章的，这时也会有部分的整理工作，这倒是额外的工作了。“池”的回归保证的是“池”内事务的完整性与“池”的运转，从某种程序上这便是企业的运转，但这也要取决于“池”的大小与企业的制度，理念了。

“池”不管是虚拟的，还是只是一个设计思路或者概念，在一定程度上，不仅在反映企业的业务逻辑，同时也是我们程序的后台设计图纸，“池”设计得好，那么整个系统在运作起来便很有一定的逻辑，程序体现的是逻辑，或者是业务。当然，无论多么复杂的去设计，修改，维护工作是一定不能少的。而我们需要做的，不管是从一开始的“池”的成立，到“池”的维护，到“池”的回归，都需要仔细的去审核，仔细的思考。

 

 

 

 

注：该文章为平时性总结，仅为个人意见，如有不妥，欢迎指点交流。

个人邮箱：[e-mail]

MSN ：[e-mail]