国庆节过了5分之四了，想想好像和没过也没有什么两样，平时没有时间做饭倒是在这个节假日弥补了，犹豫到底要不要出去，最后在犹豫中在家呆着，看着别人朋友圈散发着各种，美图秀秀和Vicotory的手势。偶尔反思一下人生的意义，好像也没有什么意义。还是伴随着不写点什么就难受的生理现象，继续写着这一篇。
上期，提到了DB 人员在一个系统设计中，基本上处于边缘化的情况，分析其原因个人认为有以下几个原因
1 DB 人员不接触业务，所以在以业务设计为主的系统设计当中没有话语权，不知道，怎么能有话语权。
2 DB 人员本身的能力不足，数据库系统本身是很熟悉，并且也熟悉相关的一些数据库原理和规范，但如果要到一个更上层次的规划，能力达不到。
3 职位的限制，一般来说一个系统的成型要软件开发以及架构师或者相关的需求经理等共同完成，而DB 在这个系统中，存在的点不明确，大白话就是存在感不强。
实际上DB 到底在一个软件系统中扮演什么角色，到底DB 是属于运维人员，还是应该 go and keep going. 实际上要迈出这一步并不容易， 首先如果你本身的数据库技术就不过关，人家问你什么，你只能答所问，你只能是一个合格的DB， 了解哪些问你问题人的背后的问题，这才是你能继续keep going的一个点。
例如：开发人员询问，我怎么才能将ORACLE 的数据，导入到MYSQL中，你提供的相关的方法，那你上升的门就被你自己给关闭了。
你要想到的，
1 他为什么要问这个问题，哪个系统要这样做
2 如果不使用MYSQL 作为ORACLE TO MYSQL 的介质，有其他可选项
3 如果ORACLE 导入到MYSQL 那数据量是否成为一个问题，尤其对于你已经知道导入的数据量比较大
4 这个要导入的系统本身原先是否有不少的存储过程，函数，以及复杂的逻辑
5 如果要使用MYSQL 到底怎么化解这些必须要去掉的存储过程，函数，以及化解复杂的逻辑
6 系统中，是否有能将一些不必要，不适合MYSQL的一些数据，转移到其他数据库中成型，例如REDIS ，MONGODB，等等
下面是两种不同的思维方式，来解决上述问题的列表
蓝色区域，只需要对操作的数据库知晓其原理，以及相关的操作方式方法和问题点进行分析，就可以解决大部分的问题。
橘黄色区域，需要了解业务，数据的详情，甚至整体的系统的架构，才能进行相关的问题处理。同时也需要掌握蓝色区域的知识。
之所以要提出这个问题，如果我们转移数据的情况下，已经从蓝色区域知道，这样的单纯的数据转换会出现问题，或很快出现问题，还是按照developers的想法照搬，虽然工作完成了，是一个合格的DB人员，可也仅仅是一个DB。
黄色的区域可能触及不到或者根本就不让你过问，但你可以自己先问问这些问题，在将这些问题的一些想法反馈给开发或者架构人员，不要怕被否决，人生就是被一次次的否决中，找到肯定的。
还以上一期的问题，（如下截图）
我们是否可以给开发一个其他的解决方案，既要使用单列作为主键，同时还满足的他的需求，也要考虑他的代码修改量。
在一对多的情况下，我们可以提出如下的方案
1 在添加一个字段作为主键，并且通过合适的算法（这里要看是单表还是分库分表），来生成系统的主键。
这样的情况下其实就可以化解相关的开发提出的多个字段在表中做联合主键的行为，满足了公司的相关的规范。
又如上期提到了，多表连接的问题，如何去化解多表连接的问题，如果你知道业务逻辑中，提取的数据大多是频繁的提取多个表的一行数据的信息。
那解决问题的方式方法就多种多样了
1 可以通过程序将关键唯一的单表信息读取到REIDS中，然后通过这一个key value 来读取各个表中关键信息，到REIDS中，在拼接成一个行信息，同时利用redis的过期KEY的设计，将读取的这个关键信息设置过期点，如果在一个时间范围无法获得这个“整行”信息，就抛弃掉所有之前读取的信息，在触发下一个查询，包装信息在某个时间范围的一致性。
2 在数据写入数据库后，将这部分信息不断的，复写到MONGODB中，并且将多个表的单行信息，变成MONGODB 的嵌套方式（当然你的确保这些表的信息不能频繁修改），将MONGODB 作为频繁输出信息的只读库，保证性能问题，也是一种方法
这些都是能将“公司规范”中不允许多个MYSQL 表进行JOIN 问题的化解的方法。
在或者通过数据库的原理，推荐使用POSTGRESQL来承接这部分数据的获取，通过POSTGRESQL 强大的数据处理功能，将这个多个表JOIN的规范打破也可以作为解决方法的一种可行性参考。
终上所述，数据库不是死的，也不是只有一种数据库，非要在这个数据库上打转转，消磨开发的力气，在一个不适合的数据库上，费尽心机。
当然首先要分析，分析业务，分析数据量，分析并发量，分析数据提取的复杂度等等，然后在给出相关的解决方案和适合的DB方案。
