最近專案中某些表在設計的時候一些金額給的預設值是0，但是在業務場景下產品說null和0是有不一樣的意義。比如說運費使用者沒填我們預設給個0那麼他就說使用者沒填就是沒填，不應該給0。給了0就認為那個金額就是0。這是不對的。在技術和產品的較量中，各自現在不同的角度來思考，到底應該聽誰的？對此你們有什麼看法？歡迎交流探討。
回覆列表
-
1 # ProblemBoy
-
2 # jinesc
我一般把運費保險費雜費之類的放另一個表裡。一個專案一條記錄。 沒有運費就沒有了記錄。也便於以後擴充。
類似財務憑證的方式。
基本包括以下欄位：
單據號
型別 ：收入/支出
專案型別
專案名稱
金額
單位
日期
摘要
//不過這樣很多人會不習慣。不過我喜歡就好了。
-
3 # Addison57
0和null區別還是很大的，首先從記憶體角度講，null比0佔的記憶體大。再一個是查詢的時候需要做判空判斷很不方便。
-
4 # 落葉11631944
如果產品不是很懂技術，那麼就把他當做需求方就可以了，雖然看似粗暴，但實際意義非常好！需求轉化為技術的時候，要根據業務場景來！
現在回答問題。從資料庫來講null和0是有本質的區別的；從業務場景來講，是收沒收費和收多少的問題。0，可以理解為收費了，但是收的是0元。null的話，就是沒收。
有個簡單的方案，也很實用。有位網友也說了，就是這樣的財務資訊單獨放在一個表裡，存在則代表收費了，無論是0還是其他的金額。這樣做，在做許可權的時候很號控制
這個問題並不應該是技術和產品的較量，相反的我個人覺得要從兩方面考慮，既要從技術角度考慮合理性，又要能夠滿足需求。
首先運費這種欄位，無論使用者是否填寫，在計算價格的時候是確定一定會加入總價的。那麼從技術上來講存null和0貌似是沒有太大區別的。但是還是從資料庫的角度來看，除非特殊情況下，通常是不建議是null作為一個欄位的預設值的。因為使用null作為欄位值，有可能會帶來一些問題，比如在包含null值的列上做count統計並不會統計到null值，比如在做負向查詢的時候沒辦法獲取到null的值，如此之類的問題還有好多。所以在使用null作為資料庫值的時候，就要考慮到是否會影響到實現。
其次從需求的角度來看，如果需求確實需要區分出使用者沒有填寫和填寫為0的情況，前提是有合理的理由，比如需要規避當出現問題時和使用者扯皮的風險之類的，那麼在這種情況下，就應該以滿足需求為前提。當然滿足需求只是說最終可以達到產品設計的樣子，而實現的技術方案還是要有技術人員去考慮的，因為在很多情況下一個問題並不是只有說是null還是0這麼簡單的，還可能涉及影響到其他的地方。術業有專攻，技術人員不應該無理由的否認產品設計，而產品人員也不應該對技術方案有過多的參與。
最後如果是我來實現這個需求的話的，我可能會在運費欄位上都為0，但是要增加一個判斷是否設定的標識位，這樣在價格運算時候不需要處理為null的值，同時可以滿足需求要求。而且如果後續還需要做其他相關的統計的時候，也可以避免一些不必要的問題。