近来因为做一个标签功能，大家讨论很多次，最终发布了一个版本。但是上线后引来用户各类吐槽。
一个标签功能应该是什么样子的？
它是灵活的，可拓展的，自由配置的，维护方便，又可以快速查询导出的。
可是实际功能开发时就遇到了几个难关，第一什么叫做灵活，那就是创建简单，而且可以支持不同类型标签，不同层级标签。系统不是AI，它哪里来的这么多灵活，一定程度上依赖于预设的规则，于是设立了支持多级标签创建，其实就是集合理念。一个标签集合下可以创建多个子级标签，子级又可以继续向下建，理论上支持到无穷多个层级。
子集合有多个，集合也可以有多个。于是这里就勾勒出一个庞大的标签体系。
这个思想有一定开放性，但是它也有局限，那就是它有很多个层级等于没有层级，因为谁也不知道用户会创建多少个层级，比如一个人建了5级，另外一个人建了10级，那后面标签如何呈现呢，如何选择呢？当层级越多，筛选和查询难度都大大增加。
这还不是最可怕的，最可怕的是如何查询出来呢，报表功能怎么做。
常规思路是预设标签个数和位置，或者灵活根据标签选择呈现。当真正纳入开发方案时，报表该怎么呈现标签呢，是放在一个单元格，还是放在一行一个，或者放在不同列。一个单元格里包含所有的最简单，但也最难用，一个终端里一堆标签堆砌在一起，如何体现层级呢。
一行一个看似完美解决了标签呈现，但是当多个标签打在一个实体上，那么导出结果可能会被放大多呗。比如一个人身上有五个标签，那么二十万人就是100万个标签显示行，如果是300万人呢，就变成了1500万行。虽然这是理论值，但是很明显一个实体上标签个数是一个不容忽视的放大器。
那就剩下按列呈现了，十个标签显示至少10列，可是要是不同地区设置不同标签，如何一起导出呢，答案是几乎无解。因为每个地区可以创建独立一套标签，于是不同地区放到一起就等于是很多个不同标签，每个都占一列，那需要多少个。比如一个城市有10个独立标签，30个城市就是300个，给它们30列的位置，无形中增加了数据展现复杂程度。
在标签问题上，前端规则的灵活导致后端报表查询和显示的复杂，有没有什么好的办法呢。最后大家提出动态显示标签字段，不要试图显示所有的，而是选择一定数量作显示。
网友评论