如题,今天要谈一谈用户的默认收货地址数据库
为何要谈这个问题,感受这是一个很是成熟的设计和解决方案了,为何还要谈。
谈这个的导火索是产品妹妹过来跟我说我们的用户地址是否是用问题,为何个人地址不是上一次的收货地址了。
而后我balabalabala说了一堆,我想咱们是想要作一好的产品,仍是要作一个产品,是为了解决问题,仍是为了更好的解决问题,
现成的京东淘宝当当能够参考的模式,咱们为何不学习一下。
而后我balabalabal说了一堆以后,让产品妹妹看了设计,看了数据库,让她再次看了本身的收货地址,而后产品妹妹说我在看看以后,走掉了。
我不知道我说的话对她会产什么影响,或者让她怎么看我。
但我本身感受咱们是为了应该更好的解决问题,是为了作一个好产品,而不是为了解决问题而解决问题,为了作产品而作产品。
因此今天把这个问题拿出来再讨论一下。 学习
我最近确实是在练习控制情绪,因此为了控制情绪,缓解压力,先来一段,不管如何都须要寻找别人优势,发现美丽,而不能吐槽,不能抱怨。
上帝给了我明亮的眼睛和锐利的智慧,是让我发现身边的优势和美好,确定上帝不但愿我对别人吹毛求疵,因此要包容,微笑。优化
好了,直接谈需求和解决方案
电商平台上用户的收货地址也是一个值得思考的问题。
咱们本身的需求是若是用户下单时不填写地址,默认展现使用用户上次购物时输入的收货地址,这都无可厚非也很合理。
可是,发现其余APP,如京东,当当,天猫等,他们设计是若是用户不输入收货地址使用默认的收货地址,这也是很合理的。
这两种不一样的方式有很大的区别和不一样,可是都很是合理,就是看各自偏好。
上一次的收货地址不必定是默认的收货地址,默认的收货地址不必定是上次收货地址。
还有就是若是本次购物填写的是全新的购物地址,则为用户新增一个收货地址。
还有设置收货地址是否默认的一个行为。设计
说道这里我都感受没有讨论的必要了,由于感受这已经很是明确了,
可是在重构建立订单时,看到每次生成订单都要去查询以前的订单,而且要查到以前最后一次的收货地址,这给人的感受就很是不爽。
那么能不能改为选地址了就去查地址表,查订单就才查订单表。
那么地址表要怎么设计怎么体现出最后一次使用。
我能想到的大概是这个样子
user_address(
int id pk,
int user_id,
string province,
string city,
string street,
string detail,code
timestamp create_time,
timestamp update_time,
boolean is_default,
timestamp last_use_time,
string hash_code -------- 能够删除了,当时不知道怎么想的。
)
我想的是大概是这个样子,一个用户有多个地址,
每一个地址都有本身的建立时间,更新时间,是否是默认地址,以及最后的使用时间。
当时也不知道是否是脑子进水了还想了一个hash值,来表示一条地址信息是否是惟一的,想一想也是多余,都忘了想哈希值的初衷了,但也把它写出来,能看到个人一个思考过程。
经过这样的设计,这样就能够根据业务需求来决定是使用最后一次使用过的地址,仍是使用默认地址了,而不是每次都要从新去从订单里去查。ci
今天谈这个目的一是想把这个设计说明白,二是想说代码真的是须要优化,而优化的前提是数据库要能支持。
再就是产品要从多用户的角度去考虑问题,本身多使用本身的产品,好用,易用,不是开发说的,不是老板的意思,而是正真的一个用户的体验。
想起了一句话说乔布斯的牛就在于他能让本身在使用产品是瞬间秒变白痴,想来那是真正的从一个用户使用者的角度去看问题,思考问题了。开发