1.设计数据库
尤其对于多人共同设计数据库，统一很重要，首先是那些东西需要统一。
1）字段名的大小写；
2）对于多单词是通过下划线区别还是通过首字母大写；
3）常用字段的数据类型和名称，比如流水号，INT，更新日期（UpdateDate，Date）更新人编号（UpdateEmpCode, NVARCHAR(20)),等等。并做到当天大家完成一份，马上碰一下，对于需要定义规则的一定要尽早说明。
4）对于长度设计几个级别，所有的长度应该只是这几个级别中选。10,20,50,200,500,1000.
5）之所以要发票头和发票Item分开保存是因为不会因为头信息的更改而导致Item跟着一起重新保存。或者Item修改导致头信息重新保存。
6）作为多主键的一个缺点是，关联的表 必须要也是要建立多字段，不及单主键关联方便。
7）至于使用数字记录枚举类型到数据库中是一件有风险的事情，如果采用这种方式，多半都是是枚举的ID，如果枚举添加类型在插入，则可能导致ID变更的问题。所以还是保存字符简写比较好。
8）对于设计一定要实现考虑各个场景和流程，想清楚后再来设计，然后拿到各个场景和流程中去验证，字段设计是否和条件。比如核销就是因为我当初只是想到了核销的时候取数据，是从集采中得到，所以没有设计表。其实如果查询历史记录，还是需要存到系统表的。
9）数据库设计还要考虑就是减少关联表。比如成本科目，科目模板，还有预算信息，其实科目模板中需要有科目的信息，这样就不需要在和科目做关联，减少表间关联。
这张关系图中预算信息表有两条路找到模板表：第一条，关联成本信息表，根据Template_ID可以取到模板表ID，再关联；第二条路，模板表中有成本ID，可以直接关联上。所以数据库设计，就是要减少关联，能够使用一张表关联就不要两张表。同样的牵涉到页面设计也尽量按照这样的设计。
10）尽量不要使用逻辑删除这样会导致开发风险的增加，这一点过于依赖于开发人员，但是对于企业级开发很多时候还是需要逻辑删除。可以将物理删除但是物理删除的数据放在一张删除表里面，横排100个字段，里面包括：TransactionID（一次批量删除的数据，便于回复），ModelCode（模块编号），BizID（业务ID，ModelCode和BizID可以确定一条记录），操作时间，操作人。可以提供批量删除恢复功能。这样避免了逻辑删除的隐患。这种方式可能需要整套系统的表都有流水号，才能统一处理，还是值得好好考虑一下。避免问题最好的方式就是依靠系统的机制这种硬约束，而不是依靠人的软约束。
11）成本科目之前是包含版本信息，这导致所有的和成本科目表关联都需要去version最大，太麻烦。我建议成本科目表就是存放最新的科目，在建立一个历史表用于存放历史的版本。对于版本的处理应该统一，我觉得最新表+历史表的方式比较好。
12）外键可以为空是有道理的，比如项目有一个字段就是项目包ID，只有当项目被当成了项目包成员才有意义。所以这个字段可以为空。可以理解为一个个体可以被包含于某个容器中，也可以不被包含，如果包含这是通过外键来关联，这种情况下，外键可以为空。
13)设计表之前将表名的前缀定义好，无论是中文的还是英文的，这样查找表的时候有索引，同一个模块的表聚合在一起。
14)数据库设计一门学问，其中考虑的点是通过字段能够反映业务完整的生命周期；比如审核时间，提交时间，指定XX信息的时间点等等；
2.数据库规范
1.在建立数据库之初就把命名规则，模块开头名称定好；另外对于中文也是一定要保证开头的模块，这样定义的好处是查找很方便。前者应用于数据库开发中，后者用于Powerdesigner的设计中，都是为了能够较为高效的使用工具。
4.需求和管理
1.所有的文档一定需要使用svn管理起来，这样成员可以依赖服务器来获取最新文件而不是本地的管理。所以依赖中央的管理，而不是客户端用户的管理，但是一定要事先将这种管理模式设计好，友好，适用。
2. 场景，和用户故事很重要，他是向别人尤其是自己组员清楚说明白来由的一种方式。所有的需求一定要场景和故事。
3.什么是管理，管理是分派（任务），跟踪（进度，变更，问题，人员），控制（范围，变更，进度，人员的思潮）。什么是控制，就是通过跟踪，将控制对象在预订的范围内。