开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。
新年已经过了，各种吉利的词汇已经过去，我们还的面对现实，现实中充斥着各种的对于数据库不好用或者管理数据库的无能者的各种侮辱性词汇。
今天我们就来看看导致数据库不好用，不能用，的那些幕后黑手是那些，你能想到一个数据库不好用的 黑手都是怎么组成的？？？
黑手 1 开发
开发是数据库的幕后黑手，或者把幕后去掉，黑手，黑手的产生源于几种类型
1 不会类型：此种类型的开发根本对数据库是一无所知，只是知道 I U D ，其他的一概不知，这种类型的开发者实际上对于数据库是一种茫然的状态，数据库对他们一直很神秘，发现各种各种的问题后，首先怀疑出现问题的一定不是自己，而是数据库。 这样的开发者们一直以自我为中心，去设想这数据库应该这样，数据库应该那样，而从来不去读读数据库的官方文档。
2 半瓶子类型：这种类型的开发者实际上对于数据库已经有了几年的使用经验，但经验的积累仅限于一些简单的数据库使用中的开发问题的解决，并没有大局观和整体观，他们的眼界局限在一个表，一个库而已，对于一些事务的问题，原子性的问题，还停留在理论阶段，例如SQL SERVER 是不是 出现事务问题就全部回滚，MYSQL 在什么情况下事务出现问题，不全部回滚，RR, RC 之间的区别是什么，是一概不知。出现问题，基本还停留在数据库有问题的阶段，但有的时候会心虚。
3 经验主义者：这类开发属于有了10多年开发经验的开发者，对于数据库的一些使用的特点能讲出一些 条条框框，如数据库不要使用大事务，数据库对于表设计的行列的宽度有一些要求，对于字段的大小也有一定的理解的程度，但是经验主义者的问题在于，知识不更新，MYSQL 8 都多少年了，对于MYSQL的认知还活在 MYSQL 5.X的知识领域，基于这样的经验，让开发对于数据库的使用不能与时俱进，还是在曾经的那些年。
以上三种是常见的开发中，对于数据库使用出现问题后，经常埋怨数据库出现问题的常见开发类型。
黑手 2 架构
提到架构，这又是另一种坑害数据库的，等级更高的一群人，这群人有几个可以总结的出的对于数据库使用中出现误区的特性。
1 架构经验循规蹈矩型：这类架构人员对于数据库的知识比上面的3类要深的多，对于数据库的使用有自己的一定见解，但有些见解是偏颇的，如 数据库使用 ORACLE 一定比 MYSQL 要强，PG 不能用，MOGNODB 是祸害等等一些理念根深蒂固，一个数据库用到 “春蚕到死丝方尽” 的地步，干什么都是ORACLE ，ORACLE , ORACLE ，其他数据库都是垃圾的思维模式，当然这样的 老架构基本上都在那些单位 ，大家也都知道。
2 创新性架构： 这类架构和上面的架构是水火不容，数据库类型什么新用什么，TIDB ， Cassandra, Couchbase , Yugabytedb 那个数据库大家没有用过，那么就是极好的，反正什么都想试试，什么都是听说，完全鄙视因循守旧的那些 老架构，想自己蹚出一条 架构设计中通往 “天堂” 的路。 这些架构在那些单位，大家估计也都知道。
3 怎么都是错的架构： 这种类型和上面的两种比较，更是可恨，前两种出事情一个是一般项目出不了大事，一个是出事会趁早，而怎么都是错的架构一般是不出事，出事就是大事，也是将DBA 推进火坑的最佳人选。
他们选择数据库是怎么不适合这个业务，我就用那种的类型，如存储大型数据如JSON ，非要MYSQL PG ORACLE 此种数据库不用，而涉及到大事务，事务敏感的部分，又开始使用MONGODB ，做聚合用MYSQL ，超高并发用PG，不该分库非要分库，该分表就照着一个表用死。最后流行一句，什么垃圾数据库的一般也是从这样的人嘴里流出的。
黑手 3 领导
领导，本来不想多说什么，实际上很多公司的数据库定性都是领导，来注意我的口型， 领导， 来决定，恰恰就是这样的领导，害死人，不懂，不懂，不懂是他们的特性，被蛇咬是一次性的，如某个项目使用了MYSQL 失败了，那么以后什么项目都不能用MYSQL ，MONGODB 看到网上说MONGODB 不安全，有数据泄露，只看标题，不看内容，然后MONGODB 就在公司了灭绝了，这种类型的黑手是最可恨的，可是你还无法和他辩驳，只能眼睁睁的看着他胡来。
黑手 4 没有数据生态和数据生命周期的业务，项目经理，产品经理
说到这里，可能你就会疑问，怎么数据库的问题都弄到业务去了，呵呵我说完你就知道他们的可恨之处了。
在产生一个项目的情况下必须对于成本有考虑，上面这些人，根本没有概念，对于项目本身的数据承载的期限，根本没有任何的想法，貌似数据就是会一直存在，至于怎么保存，保存多久， 在他们心里就是永久。
数据库不是数据仓库，数据库不是数据仓库，数据库不是数据仓库，这点的说三遍，一个项目的数据的时间要有期限，这个必须是在项目的产生时就要有一个定义的，而不是把这个问题推到数据库本身，数据库随着数据的堆积，性能会持续下降，成本会持续增高，而最终背锅的还是 DBA ，怎么连一个数据库都管理不好，这个锅一般的DBA 是一定会背上的。
那么说了这些祸害，咱们也的从自己身上找原因，如果你对一个数据库本身都不熟悉，不明了，那么自然就会产生上述的结果，如果你在接手一个项目的情况下，了解项目的特色，开发的特色，以及整体项目的 “好” “烂” 的程度，此时你就会选择出正确的数据库来对应这些 过去，现在，未来 好烂的应对手段，给出一整套拯救措施。
数据---数据库---数据处理---数据仓库--经济价值--成本
好的DB ，是要有一整套数据处理的思维挂念，而不是天天关心细枝末节，而放任上面这些人，胡作非为，最终获得 你 “好烂” 的称号。
