疫情算是过去了，真的吗？他过去了，但大多数人心里的坎还过不去，昨天回家，家里人给我展示了一堆最近购买的好东西，“各种感冒，发烧” 医治的良药，我一边赔笑着，然后从兜里拿出网上“抢”来的感冒药。
其实我知道这都是心里作用，话归数据库，三句话离不开数据库，谁让老天爷让我吃这口饭。
数据库在疫情后会有什么变化，在我自身的环境中，给我的感受是，数据库的成本部分，将是后一段，各个企业最为关心的，最近年底都在做预算，数据库的预算部分我也算了算，好家伙，一个小目标的0.1，数据库的成本在后疫情时代是在每个企业都是一个包袱。
如何消减这个包袱，可能是明年的重点，或者说可能是我明年工作的重点，怎么能降低企业数据库的成本的包袱。
我先说说我的想法，可能会涉及一些商业机构
1 在我们制定更多的技术方案中，我会着重加入成本核算的部分，尤其一些大型的项目，不能在自我放飞，数据库的选型，必须经过深思熟虑。一些share storage 的结构的产品 对比 share nothing 的产品，可能优势会更大，因为存储share storage 只有一份，而share nothing 在硬件上的成本会高。所以会严格对比两种结构的成本核算问题。
2 PG OR MYSQL ，这个问题是一个喜闻乐见的话题，大家都想整一个高低，但这里有一个不好的情况，我在数据库设计中，会尽量减少传统数据库的比重，因为程序设计中，总是愿意将数据丢到传统数据库中，而从来不想着清理的问题，数据从来没有声明周期，所以后续无论是 PG 还是 MYSQL ，必须尽量少用大型字段，JSON 数据处理等，应该将这些东西移交给更适合他们的数据库来处理，而不是压垮 PG OR MYSQL 。
3 列行混合的数据库，成为我下一个注意的目标，削减成本，一般来说在数据库部分，应该是考虑一个数据库自身解决问题的包容性，包容性更大的数据库，可以容忍更多 “烂” 开发的 “烂” SQL 的数据库，将是一个爆发，而不是挑剔类型的数据库，产品继续的泛滥。所以明年的重点必然是，有这方面类型的数据库，我要尽力的去学习和使用，对公司 和 DBA 都是一件好事。
4 数据的生命周期的理念要被推广，必须被推广，如果不推广则数据库运行后期会产生很多的数据库遗留的历史问题，导致我们带着沉重的 “脏” 数据库继续运行和维护，这也是一个需要被关注和解决的问题。
5 业务逻辑的设计，这点在很多公司都做的不好，业务逻辑设计中必然有表设计，表设计必然要懂得业务和程序设计部分，所以这部分明年我也想找一些项目试点，来看看DB 有有没有能力，将一些表设计更有规律的做好，最终能节省成本，因为数据库的，数据存储和性能，之间必然是相辅相成的。
所以，明年的重点，将是 成本 成本 成本 ！！！！！！！！
3年了，庆幸还活着，还能有工作，还能有一群做数据库朋友继续努力着，也希望各种线下的大会，开起来，3年了，我们不能只用网线连着，还是互相看看苍老的脸，更有意思。
