项目开中的一些感言

当项目已经达到一定规模的时候，负责公共代码开发的人员如果对代码做了修改，并且会影响其它开发人员原有代码的编译，应该在做出修改前发出通知，并告知在何年何月对代码进行了修改，修改了什么，修改后应该如何调用，避免大家盲目无序的工作。（具体可以参考重构中的一些做法，此处包含对数据库进行修改）

项目组成员间如何进行沟通？
对于一个项目组应该有一个自己的论坛，在论坛上大家可以留言，讨论工作中的问题（当然会议是最直接的方式，论坛只是会议的一个辅助工具）
有一个项目的Bug追踪管理系统，对于问题能够及时地做出反应
文档的及时准确性 当前我们很多小的细节都忽略了，包括现在的系统中，我们都无法提供各个类的详细文档，如果一个新手插进来，我想，他还是要晕些日子。
使用数据库建模工具，传统的用文本进行数据库script维护，已经有点......了
成员间要及时沟通，只要有一个人少沟通，代码中就会出现问题，所以例行的早会应该是需要的，半个小时，大家可以沟通交流很多事情 

 

---

 

 Views are not performance friendly! For the sake of performance do not use views. Some applications are built with multiple layers of views. This type of application design is often application convenient and can produce disappointing results with respect to database performance. There is simply too much metadata in the shared pool. A brute force method of resolving selection of rows from multiple layered sets of views is to use a form of the FROM clause in the SELECT statement with the ONLY clause included as shown in the following syntax. The ONLY clause will not retrieve rows from subset views.

从性能的角度来说，大量使用视图会带来一些性能隐患，因为有时候优化器很难在多重视图下找到合适的执行计划。使用多重视图连接，也会影响程序的易读性，从表面上看来，SQL很好读，但是从更深层次来说，会隐藏更多的业务细节，使程序的易读性反而下降。过渡使用视图，还容易造成程序员很容易用多个视图连接写出很简练的代码，但是实际上其内部包含的复杂连接和冗余数据会造成很大的性能问题。