總整理與實作練習 : MySQL Trigger/Stored Function/Stored Procedure
MySQL 提供了數種進階功能來擴展資料庫的邏輯處理能力，其中 Trigger（觸發器）、Stored Function（儲存函式） 與 Stored Procedure（儲存程序） 是三種常用的工具，分別用於不同的情境，讓資料庫更具靈活性與自動化能力。
實作練習 : 如何從實體表單轉換為資料庫表單?
這篇的重點要談到以下幾個 : (1)資料表單設計的一些實務程序。 (2)資料欄位中代碼的設計。 (3)資料表單中外鍵約束的例外。 (4)資料表單有時需要違反正規化。 (5)資料表單中有時還是需要必要的冗餘資料。 在前面 這篇 已經談過將實體表單轉換為資料庫表單，但是並沒有說明過程。這篇來說明一下過程，並且再修正一下之前的答案。 要把紙面資料電子化，先把紙面資料的欄位整理出來，然後再看各欄位適合放在哪些資料表單中。我們從上面「出貨單」，看到以下的資訊 : (1) 公司資訊 (公司名稱、電話、傳真、地址) (2) 客戶資訊 (客戶名稱、電話、傳真、送貨地址) (3) 出貨日期、出貨單號 (4) 產品資訊 (產品編號、品名及規格、數量、單價、金額、備註) (5) 經手人資訊 (助理、業務) (6) 備註 (7) 簽收資訊 (簽收狀態、誰簽收、簽收日期) 通常「出貨單」資料都會從「訂單」資料轉過來，因此之前文章產生以下表單 客戶資料表 customer(cusno, cusname, cuszipcode, cusaddress, custel, cusfax, cuscontact) 職員資料表 employee(empno, empname, deptno, emptitle) 公…
ChatGPT、GPT-4o、GPT-4o mini 哪個比較適合協助資料表設計?
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 ( …
如何使用PHP連接Excel資料表單?
Excel是不是資料庫? 在談這個問題之前，我們先實際試著使用PHP連接Excel資料表單，再來討論Excel與資料庫的關係。 PHP連接Excel資料表單，可以用以下步驟來達成 : (1) 先透過ODBC來定義資料來源。 以前在Windows介面可以由控制台透過ODBC來定義資料來源，但是到了Windows 11就找不到了，但是其實那個程式還是在Windows 11的系統裡面。 我們可以從 windows/system32/ 目錄下找到 odbcad32.exe 檔案 : 執行這個檔案之後，就會出現ODBC定義資料來源的介面了，如下圖，接著按下「新增」，開始來定義資料來源。 然後，就會看到如下畫面，選擇Microsoft Excel Driver，並按下「完成」。 接著輸入資料來源名稱，這個名稱由你自己定義，這裡我輸入了 myexcel，然後按下「選取活頁簿」。 再來選取要連接的Excel檔案，這裡我選擇了一個測試檔案 test.xlsx。 按下「確定」之後，再一路按確定回去就完成了。 (2) 再來要讓PHP知道怎麼連接這個ODBC定義好的資料來源。 打開PHP的設定檔 php.ini，找到以下設定 : ;extension=odbc 把註解符號去掉，變成 extens…
好壞資料庫結構 (database schema) 的差異是什麼?
好的資料庫結構 (database schema) 和壞的資料庫結構在多個方面存在顯著差異，這些差異會直接影響資料庫的效能、可維護性、擴展性和數據完整性。並且當開發系統時，好的資料庫結構可以讓程式容易撰寫及維護，而壞的資料庫結構可能讓程式變得很龐大，並且無法在變更系統需求時還能修改維護。 以上的說法，可能很難以理解，我們用實際的例子來說明。 我們用農民曆上的食物相剋圖來設計資料庫結構，狀況及需求如下 : (1)當兩個食物一起吃，會造成不適的症狀，例如拉肚子或是中毒。 (2)可以透過解毒物來解除不適的症狀。 我們先抓出物件 : 食物、解毒物、不適的症狀。 因此會有一個食物的資料表單，然後會有解毒物的資料表單，至於這兩個物件是應該兩個資料表單，還是合成一個資料表單，後面再來決定。 不適的症狀也會是一個資料表單，裡面會有兩個食物的欄位，如果症狀用文字表示，有違反正規化的情況，因此不適症狀資料表單中以症狀id來關連到另外一個症狀表，會比較恰當。 最後，特定症狀需要使用特定解毒物，也會形成一個解毒的資料表單。 綜合以上，形成資料表單如下 : Food（食物）：包含食物id、食物名稱和描述等資料。 Interaction（相剋反應）：包含反應id、兩種食物的id和症狀id。 Symptom（…
實作練習 : PHP + Stored Procedure + Stored Function + Trigger (三)
這個練習是從前面的練習延伸而來 : 實作練習 : PHP + Stored Procedure + Stored Function + Trigger 實作練習 : PHP + Stored Procedure + Stored Function + Trigger(二) 第一個練習在建立訂單時沒有檢查庫存；第二個練習加入「檢查庫存」，但是當庫存不足時，並不方便檢查，也不方便完成後續處理。 因此這篇文章要開始來探討，有哪些地方需要修改? 才能讓無法完成的訂購順利完成? 我們先看看原有資料表單 : -- 產品資料表 CREATE TABLE Products ( ProductID INT AUTO_INCREMENT PRIMARY KEY, ProductName VARCHAR(100) NOT NULL, Price DECIMAL(10, 2) NOT NULL, Stock INT NOT NULL ); -- 訂單資料表 CREATE TABLE Orders ( OrderID INT AUTO_INCREMENT PRIMARY KEY, OrderDate DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, Custo…
