他的第三點,special case 不好,然後他就直接 refactor 成重覆的兩個 function。
不過遇到這個問題,我還是會先套用 WET 再說 -- 也就是等到出現第二種 special case 時,再來重新思考怎麼 refactoring。
IngramChen
積分 0
snake_case 是很美好的,但是我自個是不採用,我只用 camelCase。當然啦,這樣進資料庫後會變醜,但我比較希望:
Mobile Client/Web client -> REST JSON -> Model -> Database Table 這四個 layer 裡的欄位通通長的一樣,而不是在那轉來轉去的自找麻煩。
Android/Swift/Typescript/JSON/Kotlin 通通都是 CamelCase,除非你的 tool chain 裡有 ruby 或 python,不然建議不要浪費時間在這上面。
日期是指 literal 嗎?
不然 format 成什麼樣子有什麼差?不是都 prepare statement 代問號進去?
edit: 剛看完 mysql 那篇,best practice 是 uint。LOL,mysql 果然沒下限。
hm 看到他寫 ISO-8601,但最近習慣存進去就直接 utc timestamp int。
剛剛 qrtt1 提醒了我還有這篇 Facebook 在 MySQL 裡存時間的型態1
IngramChen
積分 0
nosql 用慣了, 回去用 rdbms 就是開 materialized view. mysql 當然是沒有.
json, recursive ... blah blah 什麼都沒有