在這兩年,「 Vibe Coding (氛圍編碼)」從一個矽谷的迷因演變成了許多開發者與創作者口中的關鍵字,也讓寫不出程式的小白燃起一絲希望。有人把它理解成「用 AI 寫程式」,有人認為是「不被語法綁住,專注做出東西」。 然而隨著 AI 工具如 Cursor 、 Replit Agent 或 Lovable 的普及,我們開始發現一個弔詭的現象:為什麼同樣是用 AI 協作,有些人能在半天內做出一個可擴展的 SaaS 產品,而有些人卻在處理簡單功能需求時,系統就開始崩潰、出錯,最後陷入無止盡的錯誤循環? 關鍵在於:真正進入 Vibe Coding 狀態的人,幾乎一定具備扎實的資料庫思維,因為所有系統的主要目的都是正確的處理資料。只要你交給AI的需求與資料庫邏輯是正確的,就能產出正確的系統。 Vibe Coding 的本質從來不是在「寫 code」,而是在「組建系統」。 一、 範式轉移:從「語法導向」到「結構導向」 在傳統開發流程中,工程師的思維路徑通常是「由小到大」:先選擇程式語言,寫下第一個 Function (函式),決定 Variable (變數) 命名,最後在功能快完成時,才去思考資料要怎麼存、Table Schema (資料表綱要) 要怎麼開。 但在 Vib…
ChatGPT的 GPT-4o 是ChatGPT的最新版本, GPT-4o mini 則是GPT-4o較為有效率的版本。 我們來比較一下ChatGPT、GPT-4o、GPT-4o mini 這些版本在資料表設計上,哪個表現比較好? 先準備好固定的問題 : (1)需要設計一個線上購物的資料表結構,應該有哪些表單? (2)給我建立表單 以及插入範例資料的語法 (3)給我planttext UML 來建立 ER diagram (4)我想知道今年哪個產品銷售最好,應該怎麼寫MySQL指令? (5)我想知道A級客戶,今年最喜歡哪類產品,應該怎麼寫MySQL指令? 一、首先來看看GPT-4o的回答 以下是針對您的需求提供的設計建議和SQL範例: (1) 設計線上購物的資料表結構 一般的線上購物系統通常包含以下資料表: customers :儲存顧客的基本資訊。 products :儲存產品的詳細資訊。 orders :記錄訂單資訊。 order_items :記錄每筆訂單中的產品細節。 categories :分類產品以方便管理和查詢。 payments :儲存每筆訂單的付款資訊。 (2) 建立表單及插入範例資料的SQL語法 建立表單 CREATE TABLE customers ( …
好的資料庫結構 (database schema) 和壞的資料庫結構在多個方面存在顯著差異,這些差異會直接影響資料庫的效能、可維護性、擴展性和數據完整性。並且當開發系統時,好的資料庫結構可以讓程式容易撰寫及維護,而壞的資料庫結構可能讓程式變得很龐大,並且無法在變更系統需求時還能修改維護。 以上的說法,可能很難以理解,我們用實際的例子來說明。 我們用農民曆上的食物相剋圖來設計資料庫結構,狀況及需求如下 : (1)當兩個食物一起吃,會造成不適的症狀,例如拉肚子或是中毒。 (2)可以透過解毒物來解除不適的症狀。 我們先抓出物件 : 食物、解毒物、不適的症狀。 因此會有一個食物的資料表單,然後會有解毒物的資料表單,至於這兩個物件是應該兩個資料表單,還是合成一個資料表單,後面再來決定。 不適的症狀也會是一個資料表單,裡面會有兩個食物的欄位,如果症狀用文字表示,有違反正規化的情況,因此不適症狀資料表單中以症狀id來關連到另外一個症狀表,會比較恰當。 最後,特定症狀需要使用特定解毒物,也會形成一個解毒的資料表單。 綜合以上,形成資料表單如下 : Food(食物):包含食物id、食物名稱和描述等資料。 Interaction(相剋反應):包含反應id、兩種食物的id和症狀id。 Symptom(…
UML 統一塑模語言 (Unified Modeling Language) 是一種標準化的建模語言,可用於視覺化軟體設計和架構。常被誤會的是為何他是語言 (Language)? 因為任何系統化的、用於表示資訊或表達思想的方法都可以稱為語言。 UML 的起源可以追溯到三位著名的軟體工程師:Grady Booch、Ivar Jacobson 和 James Rumbaugh。在 1990 年代初,他們創建一個統一的建模語言,即 UML。在 1997 年,OMG 採納了 UML 作為一個標準,並從此持續管理和發展它。隨著時間的推移,UML 經歷了多次修訂,以滿足不斷變化的軟體工程需求。
今天剛好碰到王老闆,他經營了三家飲料店、兩間拉麵餐廳、三間超市。因為工讀生越來越多,每個工讀生都有不同的工作時間。王老闆希望可以開發一套工讀生薪資管理系統,讓會計人員可以登錄工讀生的工作時間來計算薪資,並記錄登錄資料的會計人員,並提供工讀生以電子郵件登入查詢自己的薪資,你覺得這個工讀生薪資系統的DFD與ERD應該怎麼畫?