感觉就好像在玩一个RPG游戏，接到一个任务，去想办法完成，完成之后获得一个奖励（某某负责人的签名），只有集满所有人的签名之后，才能顺利离职。。。人生如游戏。。。游戏如人生。。

(06.11.28更新)汗……得说明一下：我11.6就离开原来的公司了，但离职手续一直没办完，到上周末才完全办好。。我没再次离职哈。。。

嗯……当然，如果只是钱，我还不至于那么想离开公司……所以，钱只是一个因素而已，真正的原因是我对公司再也不信任了。

这毕竟关乎公司的一些内部消息，在这里我不可能全部说出来，我只能说一些要点：

1. 公司的对员工的很多承诺到最后都不了了之
2. 一些关键问题的承诺到最后居然全部推翻
3. 公司的各项措施对于底层员工并不透明，员工所知道的只是如何去执行，这样当需要作的事情风险比较大时，员工不明白公司意图，会害怕
4. 沟通机制实在够烂
5. 抠门……

在正式和公司提出离职之前，和部门总监谈了很久，我憋不住，就把对公司的很多看法全都倾吐给他，我告诉他：当一个公司并不只是对外才有诚信可言，如果内部的员工对公司失去了信心，那这个公司将岌岌可危。

今年公司的很多措施都让底下的员工不理解，而公司又不愿意就一些做法进行详尽的解释，总认为员工接收就行。而一开始的员工大跳槽，公司甚至不认为是个警讯，而把这看成是一个缩减银根的好时机，年初的时候还和我说：“要在人员减少1/3的情况下实现和去年持平甚至略有发展的盈利”……

一步错，步步错，虽然公司现在的一些项目计划很诱人，虽然公司知道我要走之后给我开出了一些不错的条件（为什么不在我提出要走之前就勾引我？一定要我失望了准备闪人才来挽留？），但是去意已决的我，已经没什么兴趣了……

公司现在的骨干人员已经走了大半，和我同批进来的同事已经走得差不多了，而公司原有的几个技术精英也已经走掉，剩下的虽然还有几个不错的人，但是和之前的技术实力相比已经不可同日而语……就好像一个堤坝，一旦决了口，很快就将变成全线地崩溃……技术精英的撤离势必带动一批技术骨干的离开，我不晓得公司现在还有什么人来作那几个诱人的项目……不要说从外面挖人，连自己的人都没留住，公司还舍得出钱来挖人吗？

在我和总监谈的时候，他说很多都是误会，谈谈就能解释得了。我说是的，都是误会，但是不去解决的误会只能越来越危险，对于公司失去信任的人们，对公司不会从好的方面去想，只会从坏的方面去想。

最后补充一句：现在zf的做法类似公司，很多事情也许不大，但是藏着掖着只能让人以为zf有什么不可告人的目的，而中国人又是一个特别善于胡思乱想的民族（思想是没办法禁止的，即使是高压政策），胡思乱想＋恶意地猜度，信任就一点点地被消磨掉……

两张表A，B，通过它们的主键相关查询所消耗的时间比使用建立一个函数，在B上遍历查询所需数据消耗的时间还长。

这么描述也许看不明白，我举个例子：

两表相关查询很简单，sql就是：

SELECT A.a, B.b FROM A,B WHERE A.id = B.id AND rownum < 1000;

而我的函数func也很简单，只是根据入参去表B中查找对应的b而已：

CREATE OR REPLACE FUNCTION func(p VARCHAR2)
   RETURN VARCHAR2 IS
   ls_val VARCHAR2(200);
BEGIN
   SELECT b FROM B WHERE B.id = p;
   RETURN ls_val;
EXCEPTION
   WHEN OTHERS THEN
      ls_val := NULL;
      RETURN ls_val;
END;

然后在sql中写：

SELECT A.a, func(A.id) FROM A WHERE rownum < 1000;

我试过很多表，特别是大数据的（10w以上……太大的表没那么多时间试验），两个执行的效率还是有一定差距。

我就在想，是不是由于两表相关查询，oracle需要在数据库中先将两张表的数据组合起来再行输出，而使用函数查询，实质上只是单表查询，而函数中的查询也使用了索引，而且由于有条件限制（rownum<1000），所以查询的次数也不太多，所以导致使用函数查询的效率反而更高？

数据库的优化真的是一件很有趣的事情，只是对于我这种还没摸进门的人来说觉得雾里看花，看不明白。

先说明一下现在的状况：

我们的b/s系统是jsp的，里面有一种“表码表”，里面存放的是一些需要经常使用而且比较少发生改变的内容，表码表是一些Map对象，而这些表码表会存放在jsp的ServletContext中。

初始化的大致代码如下：

class SysInit  extends HttpServlet implements ServletContextListener{
  public void contextInitialized(ServletContextEvent sce) {
    Map myTablePool= new HashMap();
    servletContext = sce.getServletContext();
    //往myTablePool里面塞数据
    ...
    servletContext.setAttribute("m1",myTablePool);
    ...
  }
}

然后在需要调用这些表码表的那些BO类中从request的serveletContext中获取，再进行操作：

class MyBO {
  public MyBO(HttpServletRequest req){
    Map myTablePoo l= (Map) req.getSession().getServletContext.getAttribute("m1");
    //然后就开始使用myTablePool里面的操作
  }
}

可是，今天在写BO类的时候突然想起来，这样子的做法和我在BO类里设置一个静态的私有变量有什么区别？？
下面是我假想的代码，首先还是我的SysInit类：

class SysInit  extends HttpServlet implements ServletContextListener{
  public void contextInitialized(ServletContextEvent sce) {
    servletContext = sce.getServletContext();
    MyBO.init();//调用BO类的静态方法，初始化BO里的静态私有变量
    ...
  }
}

这是我的BO类：

class MyBO {
  private static Map myTablePool = null;//我的静态表码表池
  public MyBO(){
    //先判断一下myTablePool是否为空……
    //测试过，除非initPool抛错，没对myTablePool初始化，否则不会为空
    if (myTablePool == null){
      initPool();
    }
    //直接操作myTablePool里面的数据
  }
 
  public static initPool(){
    myTablePool = new HashMap();
    //往myTablePool里面塞数据
    ...
  }
}

最早设计这套系统，使用ServletContext的家伙早就跳槽另谋高就，另外找了几个人问，都没有比较令人满意的答复，最多就是说静态变量放在内存里，如果web容器里跑的另外一个应用程序中也有一个同名的静态变量，会发生冲突……

谁能给我一个比较好的解释：类里的静态变量比较好，还是在全局的ServletContext里放着比较好？