談一談用戶的默認收貨地址

如題，今天要談一談用戶的默認收貨地址

爲何要談這個問題，感受這是一個很是成熟的設計和解決方案了，爲何還要談。
談這個的導火索是產品妹妹過來跟我說我們的用戶地址是否是用問題，爲何個人地址不是上一次的收貨地址了。
而後我balabalabala說了一堆，我想咱們是想要作一好的產品，仍是要作一個產品，是爲了解決問題，仍是爲了更好的解決問題，
現成的京東淘寶噹噹能夠參考的模式，咱們爲何不學習一下。
而後我balabalabal說了一堆以後，讓產品妹妹看了設計，看了數據庫，讓她再次看了本身的收貨地址，而後產品妹妹說我在看看以後，走掉了。
我不知道我說的話對她會產什麼影響，或者讓她怎麼看我。
但我本身感受咱們是爲了應該更好的解決問題，是爲了作一個好產品，而不是爲了解決問題而解決問題，爲了作產品而作產品。
因此今天把這個問題拿出來再討論一下。

我最近確實是在練習控制情緒，因此爲了控制情緒，緩解壓力，先來一段，不管如何都須要尋找別人優勢，發現美麗，而不能吐槽，不能抱怨。
上帝給了我明亮的眼睛和銳利的智慧，是讓我發現身邊的優勢和美好，確定上帝不但願我對別人吹毛求疵，因此要包容，微笑。

好了，直接談需求和解決方案
電商平臺上用戶的收貨地址也是一個值得思考的問題。
咱們本身的需求是若是用戶下單時不填寫地址，默認展現使用用戶上次購物時輸入的收貨地址，這都無可厚非也很合理。
可是，發現其餘APP，如京東，噹噹，天貓等，他們設計是若是用戶不輸入收貨地址使用默認的收貨地址，這也是很合理的。
這兩種不一樣的方式有很大的區別和不一樣，可是都很是合理，就是看各自偏好。
上一次的收貨地址不必定是默認的收貨地址，默認的收貨地址不必定是上次收貨地址。
還有就是若是本次購物填寫的是全新的購物地址，則爲用戶新增一個收貨地址。
還有設置收貨地址是否默認的一個行爲。

說道這裏我都感受沒有討論的必要了，由於感受這已經很是明確了，
可是在重構建立訂單時，看到每次生成訂單都要去查詢以前的訂單，而且要查到以前最後一次的收貨地址，這給人的感受就很是不爽。
那麼能不能改爲選地址了就去查地址表，查訂單就才查訂單表。
那麼地址表要怎麼設計怎麼體現出最後一次使用。
我能想到的大概是這個樣子
user_address(
int id pk,
int user_id,
string province,
string city,
string street,
string detail,

timestamp create_time,
timestamp update_time,
boolean is_default,
timestamp last_use_time,
string hash_code -------- 能夠刪除了，當時不知道怎麼想的。
)
我想的是大概是這個樣子，一個用戶有多個地址，
每一個地址都有本身的建立時間，更新時間，是否是默認地址，以及最後的使用時間。
當時也不知道是否是腦子進水了還想了一個hash值，來表示一條地址信息是否是惟一的，想一想也是多餘，都忘了想哈希值的初衷了，但也把它寫出來，能看到個人一個思考過程。
經過這樣的設計，這樣就能夠根據業務需求來決定是使用最後一次使用過的地址，仍是使用默認地址了，而不是每次都要從新去從訂單裏去查。

今天談這個目的一是想把這個設計說明白，二是想說代碼真的是須要優化，而優化的前提是數據庫要能支持。
再就是產品要從多用戶的角度去考慮問題，本身多使用本身的產品，好用，易用，不是開發說的，不是老闆的意思，而是正真的一個用戶的體驗。
想起了一句話說喬布斯的牛就在於他能讓本身在使用產品是瞬間秒變白癡，想來那是真正的從一個用戶使用者的角度去看問題，思考問題了。