postgreSQL

上週用 PostgreSQL Configuration Builder， 產生的設定增加了 ERP 效能，該機器算是硬體資源蠻差的。

昨天看到 Supabase， 它的 slogan 是 Give Your Database Superpowers 感覺蠻厲害的，裝了一下：有 Self-hosting docker 版本。 它目的是幾乎模仿firebase 的功能， 但是是以 postgreSQL 為核心，並在上層作封裝。 特色 open source 封裝 postgreSQL 有 platform 和 Self-hosting(Docker) 兩種版本，其中 Self-hosting 是完全免費 Realtime PostgREST 用 Kong 當 API Gateway Storage 目前支援 S3 相當強悍的 Authentication / Authorization 一次跑 8 個 container 如下 ⠿ Container supabase-kong Stopped 2.9s ⠿ Container supabase-studio Stopped 2.7s ⠿ Container supabase-storage Stopped 10.8s ⠿ Container supabase-auth Stopped 0....

在 2021.8 月份收到十幾年前的一間電信電纜公司寄來 mail 反應 此 anERP 系統用了 10 幾年出現了Bug (其實過去10年至少有5個 bug) 希望要我修復，花了時間回想與重建開發環境， 思考後應該記錄一下才不會忘記曾經有做過 緣起 約 2010年，有兩間 ERP 軟體公司在此間電信電纜公司執行了 7 年的 ERP 系統整合開發案，最後卻未結案。 慘到不能用，該系統不是數據對錯，不然就是輸入完一陣子後某幾筆資料突然消失，要不斷重新輸入才能儲存。 而且無法順利聯繫 PM 修改其錯誤(即使有收維護費?)。 根據以上種種原因，我提了幾個可行方案與軟體公司推薦給對方，對方考慮近半年後， 還是決定讓我獨立開發，從零開始重寫。 實際參與討論與設計後，這麼繁雜的系統真是寫滿我的休閒時間，也有點不好意思 (因為我是第 2 次使用 ExtJS，所以開發速度不快，至於為何我採用 ExtJS，是因為我認為當年的時空背景會是最佳解) 開發過程中的那一年，對方還開給我全公司存取權限 (遠端開發，這麼相信我 !!!) 需求 須滿足單位與價格至小數以下兩位 須滿足內部多公司/多部門分帳 須滿足多業主共構情境 帶一個 MIS 教他前端 + 後端 + 資料庫 各種報表集合 摘要 先說結論，最後我沒全部寫完(只釋出到 v0.9.8)，公司測試後功能是 OK 的 ( 因為後續時間跟我的線上販賣健康食品產生衝突，只好婉拒 )。 最後有點不好意思沒有 100% 寫完，如果有機會我再去彌補。 而帶一個新手 MIS 寫前端 + 後端 + 資料庫這一點最後是失敗的， 畢竟這種需要時間累積的名詞/技巧/除錯， 怎麼可能短時間一年多就學會。所以這一點我放棄了，但是有 mail 問我的問題我一定會幫。...

議題討論: 因為想把產品做 scale out 所以要用 NoSQL 取代 產品中原有的 PostgreSQL， 畢竟 RDBMS 本來就沒有 Native multi-master 的支援 !? 前提 下文感想的前提是如果技術團隊中目前沒有 NoSQL 的高手存在，但想要將 已上市的產品立即切換成任一種 NoSQL 的情境。 不包含團隊中本來就有多位 noSQL 高手的情境 NoSQL 我自己使用過 Firebase/FireStore/DataStore/MongoDB，僅是感想紀錄 先講結論 採用 NoSQL 的時間點 ? 當團隊中本來就有 NoSQL 高手 (或) 當團隊中同時有多位熟悉(多年經驗)特定 NoSQL 的 developer (或) 當團隊想開發公司/部門裡的軟體，使用自己生產的軟體(Eating your own dog food)，藉以累積實戰經驗 (或) 新創團隊，產品尚未有使用者，離上市還很遠 (或) 這是趨勢 ! 不管就是只想用 Cloud Service 上現成的或 BAAS 除了以上5點之外，建議沿用 PostgreSQL，把最新版的 pgSQL 的特性發揮應可應付絕大部分的場景。雖然 NoSQL 要設定 Scalability 的確容易得多(原生的)，但如果會產生更多不方便的地方(如下)，那何必強求容易設定 Scale-Out 這一個優點 ?...