如題，今天要談一談用戶的默認收貨地址
為什么要談這個問題，感覺這是一個非常成熟的設計和解決方案了，為什么還要談。
談這個的導火索是產品妹妹過來跟我說咱們的用戶地址是不是用問題，為什么我的地址不是上一次的收貨地址了。
然后我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值，來表示一條地址信息是不是唯一的，想想也是多余，都忘了想哈希值的初衷了，但也把它寫出來，能看到我的一個思考過程。
通過這樣的設計，這樣就可以根據業務需求來決定是使用最后一次使用過的地址，還是使用默認地址了，而不是每次都要重新去從訂單里去查。
今天談這個目的一是想把這個設計說明白，二是想說代碼真的是需要優化，而優化的前提是數據庫要能支持。
再就是產品要從多用戶的角度去考慮問題，自己多使用自己的產品，好用，易用，不是開發說的，不是老板的意思，而是正真的一個用戶的體驗。
想起了一句話說喬布斯的牛就在於他能讓自己在使用產品是瞬間秒變白痴，想來那是真正的從一個用戶使用者的角度去看問題，思考問題了。