最近业务部门在选择新的AF 系统（具体不能说的太细，能明白AF在某个行业代表什么的估计能看的懂）。之前业务部门购买系统一直是平自己的喜好，功能满足，几百万就花出去。可惜的是功能是满足了，但性能满足不了，在整体的应用中，成为了一个瓶颈。业务部门吸取了相关的教训，在采购新的AF系统的情况下，将数据库方面作为一个考虑的对象，当然我自己也深知为什么，之前的两年一直在和老的AF系统的供应商PK 数据库方面的问题。
这里顺便离题一下，软件供应商的产品在销售的过程中不是特别考虑在性能上面的介绍，大部分都是面对功能方面的介绍，并且在介绍相关的案例的时候基本上也不会介绍这个系统在数据库方面的扩展性和性能。这是必然，也是大多数公司购买了系统后，在运行一段时间后，发现不好用，的一个原因。
所以在购买系统的时候，公司有相关的开发技术专家，和数据库方面的技术专家的重要性毋庸置疑，否则你就是案板上的肉，人家不割你割谁。
之前的老供应商的产品是基于SQL SERVER 的一套AF 产品， 数据量不大，但已经有了瓶颈，并且这家供应商也不具备服务数据库底层的能力，这两年问题频出，那自然就是要被替换了。主要的问题在于产品的设计中无法扩展，并且是面向数据库的设计模式，这样老掉牙的设计模式，和上世纪的流行风倒是很搭配。
最近约的一些供应商，已经在抛弃这样的开发方式，数据库方面也都是MYSQL ,POSTGRESQL ，REDIS 这样的数据库组合模式。但实际上在听这些供应商的介绍后，发现两点问题
1 不考虑甲方的架构运维支持的能力，直接搞来一套需要耗费大量精力的系统，例如直接拿来 MYSQL MYCAT HAPROXY KEEPALIVE的架构，说实在的，这要是互联网那没有问题，但到了financial enterprises 这就是一个问题，并且自身还不提供这样一套产品的维护，这就有点说不过去，所以在一个产品设计之初，除了软件上层架构的设计，数据库方面的设计也的注意，你不能拿来这样一套产品，让企业去琢磨怎么来维护这样一套产品
2 即使是购买的产品，对于数据库的要求尤其是甲方的要求，也在变得越来越高，虽然产品中可以选择ORACLE ，POSTGRESQL ,MYSQL 等数据库作为基础数据库，但乙方是不会提供相关数据库方面的支持，所以还需要甲方的人员有类似数据库的运维和管理的能力，并且有些单位在某些系统上已经拒绝了商业数据库，产品的开发方在软件的研发中，支持多种数据库，就怕是换汤不换药，曾经我问了一家机构，如果我们选择ORACLE 和 MYSQL 两种不同的数据库（乙方说支持两种数据库，择一即可），在软件方面的设计有哪些不同点，告知没有不同。心里瞬间就凉了一截，这样的设计.........
要不就是在上层软件层来解决了，那自然是极好的，说明公司实力强，数据库已经沦为了容器而已，要不就是要使用一个可能张冠李戴的应用，在后面的使用中，继续忍受一个程序，几个数据库都可以的，“烂”程序。
在深入的去了解，就会涉及到软件开发公司本身的架构师的水平，软件在使用不同数据库的时候，如果了解不同数据库的软件开发的特性和运维方面的特性，必然是说不出应用系统使用哪个数据库都行的“豪言”。另外一个应用系统如果仅仅选型一种数据库，也要当心，例如有些供应商将文件存储进MYSQL ，12行数据库，7G 的设计方式，也是...... 让我大开眼界.
总结
1 公司在购买软件产品，不光需要业务部门介入，同时也需要技术部门介入(希望你公司有技术部门，要不挨骗，挨宰，就认头吧）。通过技术部门在软件的方面对软件的设计和数据库方的设计以及后续的运维成本进行评估，才能让这个几百万的产品能好好的服役于公司几年。而不至于重复投资。
2 公司应该重视技术部门，不重视技术部门，可能就是，人财两空，软件产品设计上达到业务的基本和扩展的功能是必然的，但仅仅满足功能，不考虑性能,并发,解耦，则和上了一堆废铁也没有什么区别，而大多外部软件项目的失败大多不是功能方面的问题，而是软件在并发和数据方面无法承载业务的增长的问题。
对于乙方的公司也是，你提供的产品如果甲方没人懂你的架构毛病，或者数据库设计的缺陷，那你的销售倒是可以蒙一蒙，骗一骗， 但如果人家有懂行的，那不入流的做法，可能人家一句话你就被打入冷宫，千万别以为自己三寸不烂的舌头，能扭转自己公司不入流的设计和蹩脚的数据库选型，终究一个你是要打造一个“一锤子”的买卖，还是绵延留长的合作关系，还是要依靠产品的硬实力。所以好的销售如果发现自己公司的产品不入流，劝你一句良禽择木吧。
