每当遇到一致性问题我就思念一个数据库好

最近在做一件事情，让我苦不堪言。就是各个系统之间的数据标准。这个标准包含，字段名，字段含义、字段类型、字段长度和字段的值。

不同系统中，同义不同名。例如，卡号可能是CARD_ID,也可能个是CARD_NO或者CARD_NUM，当然也可能是不带下划线等等。这里数据类型还不太可能不一样。但是有些字段比如时间，连数据类型可能都不一样，比如有的是时间型，有些是字符型。

不同系统中，同名不同义。例如，A系统的STATUS，表示发送状态。B系统STATUS，表示支付状态。

不同系统中，值代表不一样。例如同是支付状态。A系统的1表示全额付款，B系统的1表示部分支付。

这些最后都反馈到使用中，出现各种各样的麻烦。当然如果一开始由专业的数据库人员来主导这些也就没事了。但是现状就是之前毫无规范，现在开始收拾就是积重难返。

接下来就是要梳理出几十个库，上千表，上万个字段的。这就要协调所有开发团队来进行梳理。每个开发团队都很忙，实在是太难了。

试想一下如果这些都是一个数据库实例中（毕竟我工作前10年都这样做各个系统都在一个数据库实例中）。各个系统访问其他系统的数据通常采用授权访问的方式，这样的优点：

1. 最大限度上去掉了接口。减轻了相关开发工作量。
2. 最大限度上减少了中间件。
3. 提高了系统之间的交互效率和稳定性。
4. 减少了系统交互的流通环节和瘦身了架构。
5. 以上种种数据标准的问题都解决了。

可能还有，不一一列出了，因为优点实在是太多了。

这种做的缺点：

1. 一个数据库宕机，全部系统都不可用。仅此一个。

原本我想写一个这种对开发素质要求高。后来想想没必要。因为如果分成10个数据库，但是其中的基础数据库不可用了。比如会员数据库。那么其他数据库都是好的，也基本是瘫痪的。

话说回来，这个不是应该是基本素质吗？只是现在很多个人和企业都不重视了。每当进度和质量发生冲突，是保进度而不是保质量。这其实是无法放到台面上说的。项目管理不允许，公司管理也不允许。如果哪个工程被采访时候说进度来不及，牺牲一下质量。估计马上就会被问责。反之如果说，要保证质量延期，则不会有什么质疑。

而且就风险和收益来说，我觉得应对风险的成本单实例成本低，性价比高。

总体来说还是我一直鼓吹的一个数据库最好（在中小企业适用）。这里说的中小企业是说传统行业，但是不包括几大行和运营商以及互联网公司。