在项目实施或者二次开发过程中的一些小设置，很可能会给日后运维制造很大麻烦，而这些并非都只适用于各种事后诸葛，其中的一些其实是我们可以规避的。
这个title没有别的意思，就是想说明这种事情很悲剧，为了运维兄弟少加班，多多体谅下是有必要的。
1、自建数据源一定要把选择条件放宽松，不然一条单子出了错，就要跑N多数据。如果有Delta机制的话，一定要注意设置Safe Limit。
2、InfoObject如果不是特殊需要，一定要把ALPHA转换去掉，不然以后转换例程里面如果没有对结果进行ALPHA转换，数据加载或者激活是要报错的。
3、Query也许可以临时建，但是变量一定要用传输的，保证三系统一致，不然后果就是Query Designer里满屏红啊，单个Query重复也就重复了，变量可是每个Query都用的啊。
4、 CUBE的字段不是越多越好，人家本来就是汇总级别的，如果要搞明细数据一定要放在ODS里面，非要用CUBE就在上面加一层。CUBE里面千万别进行 Key Figure计算或者用来随便找个字段置成1就算计数器了，这些动作一定要在ODS层面做，一来写起来很复杂，二来很容易出错。
6、ODS的主键是关键，不仅建模的时候要慎重，写例程的时候也要多考虑主键的影响，非主键的字段尽量不要在结束例程里参加计算或者筛选，那都是被覆盖过的啊。
7、所有模型的时间变量，比如日历日，日历月，日历年之类的，应该是全的，别吝啬这几个字段，Query里面如果要用这些字段最好统一变量。
8、标准数据源里一般都提供了所有需要的数据单位，这些很重要，不要忽视啊，你可以都在后来做成RMB，万一有一天用到Dollar呢，这种事情，时间越久越难搞啊。
9、不用的模型赶紧删掉，以后就更不敢删了。
10、有标准的，尽量用标准的，如果自己非要做，不如做一套，告诉大家都用你这套，重用性是节约生产力的关键啊。
11、千万不要把设置都写死，比如infopackage限制2011年啊之类的操作，完全可以用代码灵活处理，特别是用处理链加载的模型。
0、想起来再续...