表字段过多的业务如何设计？

Question

场景

1. 某业务需要集成其它几个大平台的数据，这几个大平台的数据需要通过API直接调用或者抓取文件解析等方式取数据。
2. A、B、C三个平台的接口返回字段合计后有将近400个，每个平台接口都有100多个返回字段，且字段的含义有的相近，有的不能理解成同一个意思。
3. 现在产品和优化师挑出来300个需要用到（计算、展示、存储）的字段，那么该业务如何设计数据库比较容易维护以及开发呢？
4. 这样的业务不止一处，有好几个类似的业务，当前是用Mysql做垂直分表，系统在使用了大半年后，经过优化师不停的加字段和需求，维护的难度逐渐加大，数据量也在加大，所以有重构的计划。
5. 所以想请教一下，在重构的时候有什么好的解决方案吗，比如常说的数据转换层具体应该如何实现呢？如果选择MongoDB等相同的业务放到一个集合中以文档的方式存储会不会比较轻松？
6. 系统设计经验不足，请各位不吝赐教。

Answer 1

1. 首先数据来自不同的平台，那么采集数据应该按照对方平台的设计进行存储源数据，看需求吧，是否对查的字段进去取舍
2. 如果你多个平台的数据展示在一起，那么将数据合并一张表，那么这个每个字段的存在都知道考虑

Answer 2

得看具体需求吧，用于筛选的字段可以存在一张表里，其他的字段可以放在各个联表中。
此外设计不是一成不变的，需求变了，设计就要跟着变。没有完美的设计。