周末之个人杂想（十七）
BI从业这些年，遇到过狠多不同的业务系统。经常会有朋友问我说，业务系统应该提交给BI系统中什么样的数据。这类问题总是需要自己反过来问自己的问题，比如如何根据一个日期计算是当年的第几周，还有为什么报表上的数字不准确等等。业务系统应该提交什么样的数据，这个问题更应该去问业务系统本身，业务本身确定吗？业务系统的运行状况健康吗？把这些问题整清楚了，这个问题也就不需要问了。
所以在此罗列了些那些年遇到过的奇葩的和令人惋惜的OLTP，同时表达下当初面对这些情况时的无奈的心情。
非要折腾数据库
那是一个算奖金的系统，系统有一个很变态的需求就是需要将所有的数字类型的值在数据库里都是加密存储的，以防止不被授权的人获取管理员账号和密码之后能登陆到数据库系统中查看到敏感的内容。
管理员的账户安全，其实这本是行政上的是，但非要在IT的层面上来解决，结果，就是，每次算个奖金，都要四个多小时。而后来想到的优化方案居然是，换成Sun的OS加Oracle的数据库，结果不用想，连OS都没配明白。其实，这样在极端情况下逼迫出来的方案也绝对是一个"怪胎"，就这样的方案，你换成啥都不好使。本来奖金的核算就需要大量的数据加载和计算，中间再加上这些对单元数据加密和解密的过程，平白加多了大量的性能开销。
还有一个网站，算得上是奇葩，要求网站上所有的图片，都要以二进制的形式保存到数据库中，理由就是为了后续维护人员后期对图片的更替。我到现在也无法理解，当时的PM已经二到了什么程度，不跟用户阐明到数据库里改一个二进制的数据和到一个文件夹替换一个图片到底哪个更容易些。
尴尬字典项
往往业务成熟度不够的系统中最容易有这样的问题。比如一个存储人员的信息表中，你会看到，性别的字段上居然有超过六种类型。除了我们知道的两个类型之外，其余的基本上都是"未知的性别"，"无法确定的性别"以及"尚未确定的性别"这样的值。
好吧，先不说这样的设置在现实世界中是否合理，但我看不过去的更多地是在OLTP操作界面中，性别的选择框，除了让用户选则之外，还可以让用户直接在上面输入。也许这样的设计可以作为"靓点"来忽悠客户，但不收敛的离散字段在信息系统中简直是个灾难，因为沉淀下来的信息很容易就成了垃圾信息。
最后还有那种比较奇怪的，也是在上一个系统中出现的，就是性别的字段，0和1这是正常的，但你总能找到全角的0和1，基本上就是这种坑爹的设计留下的恶果。
Over SOA
在网球中，假如一个球力度过大，打出界了，这叫over hitting。Over SOA这个说法的引申含义，基本由此而来。
在我遇到过的一个系统中，SOA被架构师忽悠的简直无敌了，于是，同样要求BI端对于OLTP的抽取要走SOA的接口，而且无论任何程序访问BI中的数据也要经过SOA（包括Excel通过透视表连接多维数据集）。就连ETL的中间过程甚至都不放过。
我不是SOA的专家，但是我知道走接口的话会带来额外的性能开销。OLTP通常单笔操作的数据量很小，这种性能开销有时也许可以忽略，但是BI系统中单笔数据量会很大，而这样的性能开销就比较悲观。而且还要在现有的成熟工具上去编写能够读取SOA接口的中间层，这个工作量简直就是个灾难。
最后顺便说一句，那个项目，已经做了五年，已经做到了不只第五期，微软MCS的人换了不下三批，Vendor的人一年一换，截至到目前仍未上线。
加密？
经常有人问到我说，如何才能让报表中的数据不被篡改，其实如果有PDF或者Portal的话可能还好说，单这不是绝对的安全，现在改个PDF的内容已经不是黑客的专利了，再比如说将报表中的数据导入到Excel中，如何保证数据不被更改。
其实关于这个我想说，这些本来还是行政方面需要解决的问题，就不要强加到IT层面了。一个给老板看的报表都敢更改的人，像这样的人应该怎么被处理掉，各位还是看着办吧，偶在这里就不愿意多费唇舌和笔墨键盘了。
有时候想一想，为什么在上地软件园的很多公司都有严格的打卡制度，而像微软这样的公司就不需要打卡（指微软中蓝卡的兄弟），这是一个道理的。
巧妇难为无米之炊
每年都会有人联系我说他们的创业公司，在做一个什么什么样的系统，打算上BI，希望我能帮忙。也许其中的朋友此刻正在看我这篇文章，但我想说我真的不是看不上谁谁谁或者怎么样，但问题是，您的产品开始做了吗？圈内总有这样的事，比如前段时间看到的一个婚恋网站，还没开始做呢，红娘先请了一批，结果，业务系统不上线，业务就无法开展，而红娘那边无法进行实质性的业务，还得给那些红年们发工资，然后，就没有然后了，因为那家网站不久就倒闭了。而那些几年前找我的朋友，现在也都散了伙。在此，真的不是想嘲笑那些朋友们的创业想法（有些创业想法还真的事很靠谱的，但知识有些哦！），或者是五十步笑百步，而是当时的我，真的没有什么能帮得上忙的，但是有些话在那个时候还真的无法直说，尤其是在正处于创业激情顶峰的朋友。