昨天反思并整理了一下价目表视图的主要需求，以及概念层面的设计考虑，今天继续一些昨天没有谈到的细节，也有一些昨天写完以后的发现忽视的地方。
细节一，昨天我们说把如何计费包括，单价，货币，计费单位信息放到价格的格子里：
计费方式也类似，其中的单价，计费单位和货币可以放到对应的可以价格格子里。
从需求的角度讲是OK的，但实际上还是会给实现带来较大的复杂度，主要的原因是正常情况下一个价格的格子只一个价格，那么用户是填写是修改都听清楚，如果把计费单位放到里面，那么就有可能会存在两个其他完全相同的，只有计费单位不同的价格条目。
实际上现实中也是存在的，一个订单可能可以按重量计费，也可能按体积计费。其他条件就可能完全相同。这样一个价格的格子里挤了多个价格数量，如果只是看还可以，还需要编辑修改就很复杂了，还不如分两行显示清楚。
细节二，既然这个pivotal view是一个按条件分组组合的视图，那么这个分组是在显示的时候决定呢？还是在保存的时候决定。
更灵活的方式一定是在显示的时候决定，因为这样分组条件可以随意修改，不影响价格条目本身，也可以实现不同的人有不同的分组条件。
不过当这个分组条件越来越复杂时，显示的时候分组就会带来一些性能问题，特别是当分组完之后的行数是很难估算的，所以对分页显示带来困难，实际上目前TMS的价目表视图没有作分页很大程度就是这个原因。
那么妥协的方式就是在保存的时候把分组分好，记下分组信息，那么在现实的时候根据分组信息排序后显示就行了，当然他带来的的问题是一个计费条目只能对应一个分组视图，当切换或者修改分组视图时要重新计算分组。
细节三，昨天有几位同学提到说目前的计费条件的表设计存在很大的改进空间，原因是通常一个计费条目的计费维度数量在五个左右，但是你把所有计费条目的维度做个并集，计费维度的数量就突破100个了，把这*100个维度平铺在表中，实际的利用率就只有百分之五。这块可以考虑下有没有什么优化的实现方式。
细节四，分级报价的分级是不是一种计费维度？我的理解是是的，只是他的维度的匹配方式与其他正常的维度不同，正常维度可能是一个等于的匹配，他就应该是一个within的匹配，其他我认为没有区别，实际上我们的地理位置类型的维度是一种更复杂的匹配模式，我们也认为他是计费维度。如果是这样理解，那么我们可能就不存在分级报价或者双重分级报价了。
细节五，我们的计费单位，这里目前是一个大杂烩，里面有千克，吨，升，立方米，单，箱，天，小时，件数等等。你会发现这里违反了我们之前提到的一个重要tip，叫正交性，他把两个维度混在一起了，一个是计费量，一个叫计费单位，计费量说的是按什么值计费，可能是毛重，净重，体积，运输箱量等等，计费单位说的是物理量的单位比如重量是用克，千克，还是吨。如果把这两个混在一起就变成了一锅粥，甚至计费单位现在还有出现20gp的，明显他应该把计费维度设成20gp,把计费单位设成箱。
看上去tariff的规范化重构任重而道远啊...
网友评论