你这个数据太分散，如果业务逻辑一直成功执行倒是没啥问题，不过一旦哪里出问题了，你要查询与排错就非常麻烦。

我遇到这种跨多个子系统的复杂流程，喜欢先设计一个超大的表单式数据结构，把所有的状态、时间、各种细节日志信息，都写在一条数据的字段里，这样查询方便、排错也方便。拿你这业务举个例子：

struct BuildAds
{
# BuildAds 数据区域
uint64 id;
uint64 用户 id;
uint64 部门 id;
uint64 批次 id;
uint64 策略 id;
datetime 创建时间;
uint64 调试 id;
uint64 调试链顺序级别 id;
uint64 调试链同级内部 id;
...其他 BuildAds 数据字段...;
#
# 素材处理数据区域
bool 是否需要处理素材;
datetime 素材列表开始处理时间;
datetime 素材列表处理超时终止时间;
string 素材列表处理超时终止细节；
datetime 素材列表处理错误时间;
string 素材列表处理错误细节;
List<struct 素材> 素材列表
{
string 素材 name;
uint 素材 size;
datetime 素材创建时间;
uint 素材创建用户 id;
datetime 素材开始上传时间;
datetime 素材上传最后一次中断时间;
datetime 素材上传最后一次续传开始时间;
datetime 素材上传超时终止时间;
string 素材上传超时终止细节;
datetime 素材上传其他错误时间;
string 素材上传错误细节;
datetime 素材上传完毕时间;
enum 素材上传状态; # 未开始上传、上传中、上传中断、续传中、超时终止、其他错误;
string 素材文件路径;
...其他素材文件数据字段...;
};
#
# 广告数据区域
datetime 广告开始搭建时间;
datetime 广告搭建终止时间;
string 广告搭建终止细节;
datetime 广告搭建错误时间;
string 广告搭建错误细节;
datetime 广告搭建成功结束时间；
...其他广告搭建数据字段...
enum 当前业务状态; # 已创建、素材处理中、素材处理终止或错误、搭建广告中、广告搭建终止或错误
}

我之所以会这样设计，是因为以前我设计过一个更复杂的业务，一套分布式多媒体系统，文件被人为移动过，但不知道从哪移动到哪里。业务逻辑是，要在多媒体列表里，把这些被移动的缺失的多媒体文件，找出来并更新多媒体列表。首先要解析多媒体列表，解析可能失败；然后备份列表文件，备份可能失败，备份可能重名；接着轮询多媒体列表里的每一条媒体文件数据，去全盘寻找，核对 HASH ，以及去重处理；接着有些多媒体文件能找到，有些找不到，这些也要处理。这里面一大堆状态，只有这种把状态与错误信息集中起来的超大表单式数据结构，才能方便开发、查询与排错。不然一旦数据结构分布在各个子系统中，查询与排错就巨麻烦，开发与排错效率巨低。