changyuheng 積分 0

直接違反機器人三定律第一條。

changyuheng 積分 0

之前比較 v1 和 v4 時就覺得 v4 有重複的機會,硬體 ID + timestamp 保證 unique 不是更好嗎?

IngramChen 積分 3

最後大家還是要時序的 UUID...

IngramChen 積分 0 編輯於

他的第三點,special case 不好,然後他就直接 refactor 成重覆的兩個 function。

不過遇到這個問題,我還是會先套用 WET 再說 -- 也就是等到出現第二種 special case 時,再來重新思考怎麼 refactoring。

ksc91u 積分 1

“The difference between xhyve and hyperkit” by Charley Chen https://medium.com/@hintcnuie/the-difference-between-xhyve-and-hyperkit-67a9f378ab97

ksc91u 積分 0

人也會判斷不出來

用電腦的好處是 假設我有 ABCD四張不同時間拍攝的 可能A時間點還看不出來 但是 BCD 之後出現腫瘤 我可以把A也標示成有腫瘤去訓練

IngramChen 積分 0

遠景比較霧的部份也沒有被銳利化,神

IngramChen 積分 0

我好興奮,我好興奮啊 ! (tm)

koji 積分 0

你現在postgres時間用 timestamp with tz?

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,不然建議不要浪費時間在這上面。

IngramChen 積分 0 編輯於

日期是指 literal 嗎?

不然 format 成什麼樣子有什麼差?不是都 prepare statement 代問號進去?

edit: 剛看完 mysql 那篇,best practice 是 uint。LOL,mysql 果然沒下限。

IngramChen 積分 1

這樣母湯喔… 變快或變慢的原因都要去了解

kaif 積分 0

如果DBA不給力還是要有個保險可以刷卡callout percona阿xd 目前是都還沒用到就是了。

之前大部分問題是加ram讓資料進記憶體就會乖乖了,最近碰到加記憶體還是慢的,升版mysql速度居然快好幾倍,不知道是原來太爛還是oracle黑科技太威

IngramChen 積分 0

資料庫會出什麼事?出事不是都自己搞砸嗎?

kaif 積分 0

我用mysql主要還是出事找的到人support, 加上oracle下放很多黑科技

IngramChen 積分 0

nosql 用慣了, 回去用 rdbms 就是開 materialized view. mysql 當然是沒有.

json, recursive ... blah blah 什麼都沒有

haocheng 積分 0

用了 MySQL 一陣子好懷念 PostgreSQL 的 JSON 功能... PostgreSQL 可以直接對 JSON 欄位做 index,MySQL 要用 virtual column 來處理才行...