對資料庫的大體理解

資料儲存部分

資料表（Tables）

• 資料表是資料庫的核心組成部分，用於儲存資料。它們由行（記錄）和列（欄位）組成。例如，在一個電商資料庫中，會有 “產品表”，其中的列可能包括產品 ID、產品名稱、價格、庫存等，每行代表一個具體的產品記錄。資料表的結構定義了資料的儲存格式，不同的資料表用於儲存不同型別的資料，並且可以透過關聯欄位（如外來鍵）建立表之間的關係。
• 除了基本的資料表，還可能有檢視（Views）。檢視是基於一個或多個資料表的虛擬表，它不儲存資料本身，而是透過查詢定義來展示資料。例如，可以建立一個 “暢銷產品檢視”，它透過查詢 “產品表” 和 “銷售記錄表”，按照銷售數量排序來展示最暢銷的產品資訊。檢視可以簡化複雜的查詢操作，並且在一定程度上提供資料安全性，因為使用者只能看到檢視所展示的內容，而不是基礎資料表的全部資訊。
• 還有索引（Indexes），索引是一種資料結構，用於加速資料的查詢。它類似於書籍的目錄，透過建立索引，可以快速定位到需要的資料。例如，在一個包含大量使用者記錄的 “使用者表” 中，為 “使用者名稱” 欄位建立索引後，當透過使用者名稱進行查詢時，資料庫可以更快地找到匹配的使用者記錄，而不需要全表掃描。

使用者管理部分

Root 使用者（或超級使用者）

• 擁有最高許可權的使用者，類似於系統管理員。在資料庫系統中，root 使用者可以執行任何操作，包括建立、刪除和修改資料庫、資料表、使用者等。例如，root 使用者可以使用資料庫管理系統提供的建立使用者命令（如在 MySQL 中的CREATE USER）來新增新使用者，使用GRANT命令授予使用者許可權，使用DROP DATABASE命令刪除整個資料庫等操作。root 使用者還負責資料庫的整體配置和維護，如設定資料庫的引數、備份策略等。

普通使用者（Regular Users）

• 普通使用者是透過 root 使用者或具有相應許可權的管理員建立的。他們的許可權由管理員授予，並且可以根據業務需求進行定製。例如，在一個企業資源規劃（ERP）資料庫中，普通使用者可能包括倉庫管理員、銷售代表、財務人員等。倉庫管理員可能被授予對庫存資料表的插入、更新和刪除許可權，以管理貨物的進出庫；銷售代表可能被授予對客戶訂單表和產品表的查詢和插入許可權，用於處理銷售業務；財務人員則可能被授予對財務相關資料表的各種許可權，用於進行財務管理。

資料處理部分（儲存過程（Stored Procedures）和函式（Functions））

• 儲存過程是一組預編譯的 SQL 語句，它們被儲存在資料庫中，可以被呼叫以執行特定的任務。例如，在一個銀行資料庫中，可以建立一個儲存過程用於處理轉賬業務，它接受轉出賬戶、轉入賬戶和轉賬金額等引數，在儲存過程內部執行一系列的 SQL 操作，包括檢查賬戶餘額、更新賬戶餘額等，以確保轉賬業務的完整性和準確性。函式與儲存過程類似，但通常用於返回一個值，例如可以建立一個函式用於計算產品的折扣價格，根據產品原價和折扣率返回計算後的價格。
• 觸發器（Triggers）也是資料庫的重要組成部分。觸發器是在特定的資料庫事件（如插入、更新或刪除資料）發生時自動執行的一段程式碼。例如，在一個庫存管理資料庫中，當有產品銷售記錄插入（表示產品被銷售）時，觸發器可以自動更新庫存表中的庫存數量，確保庫存資料的實時準確性。

系統配置和管理部分

資料庫配置檔案（Configuration Files）

• 資料庫配置檔案包含了各種引數，用於設定資料庫的執行環境和效能。例如，在 MySQL 中，my.cnf（或my.ini）檔案包含了諸如快取大小、最大連線數、儲存引擎預設設定等引數。透過修改這些引數，可以最佳化資料庫的效能，以適應不同的應用場景。例如，增加快取大小可以提高資料的讀取速度，而調整最大連線數可以確保在高併發情況下資料庫能夠正常處理客戶端的連線請求。

日誌檔案（Log Files）

• 日誌檔案記錄了資料庫的各種活動，包括使用者登入、資料操作、系統錯誤等資訊。例如，事務日誌（Transaction Logs）記錄了資料庫事務的詳細資訊，用於在系統故障時進行恢復操作，確保資料的完整性和一致性。查詢日誌（Query Logs）則記錄了使用者執行的 SQL 查詢，這對於效能分析、安全審計等方面非常有用。透過檢視日誌檔案，管理員可以瞭解資料庫的執行狀態，發現潛在的問題，如異常的查詢操作或安全漏洞。

對資料庫伺服器端和客戶端的理解

考慮因素

• 安全性方面：為每個 APP 使用者建立一個 MySQL 使用者可以提供更高的安全性。這樣可以精確控制每個使用者的訪問許可權，並且在出現安全問題（如密碼洩露）時，僅影響單個使用者的資料訪問，便於追蹤和管理。例如，如果某個 APP 使用者的 MySQL 賬戶出現異常訪問，能夠快速定位到該特定使用者，而不是影響整個 APP 使用者群體。
• 管理複雜性方面：然而，為每個 APP 使用者建立單獨的 MySQL 使用者會增加管理的複雜性。這意味著需要處理更多的使用者賬戶，包括建立賬戶、設定初始密碼、管理密碼重置等操作。而且，隨著使用者數量的增加，資料庫伺服器需要維護更多的使用者連線資訊，這可能會對伺服器效能產生一定的影響。

簡單 APP 場景下的選擇

• 對於一個類似線下小商店的 APP，如果使用者數量相對較少（例如，少於 1000 個活躍使用者），且對安全性要求較高，為每個 APP 使用者建立一個 MySQL 使用者是一個可行的選擇。可以透過在使用者註冊 APP 時，自動在 MySQL 中建立一個對應的使用者賬戶，並根據使用者角色（如顧客或店員）分配相應的許可權。
• 例如，當一個新顧客註冊 APP 時，後端伺服器在 MySQL 中建立一個新使用者，授予其基本的顧客許可權，如查詢商品資訊和下單的許可權。對於店員使用者，除了基本的查詢許可權外，還可以授予庫存管理和訂單處理等許可權。

複雜或大型 APP 場景下的替代方案

• 如果 APP 預計會有大量使用者（例如，數萬個或更多），為每個使用者建立一個 MySQL 使用者可能會變得不切實際。在這種情況下，可以考慮使用一個或少數幾個共享的 MySQL 使用者來代表 APP 使用者群體。
• 可以透過在 APP 的業務邏輯層對使用者進行身份驗證和許可權管理。例如，使用一個具有較高許可權的共享使用者來處理 APP 使用者的請求，在 APP 內部透過使用者令牌（token）或會話（session）來識別每個使用者的身份，並根據使用者的操作（如查詢商品、下單等）檢查其是否具有相應的許可權。這種方式需要更加嚴格的應用程式安全措施，如對使用者輸入進行嚴格驗證、防止 SQL 注入攻擊等，以確保共享使用者的許可權不會被濫用。

對資料表的理解

行（Records）

• 資料記錄的集合：資料表中的行代表了一組相關的資料記錄。每一行都包含了表中各個列所定義的資訊，就像是資料庫中的一個實體。例如，在一個員工資訊表中，每一行代表一名員工的完整資訊，包括員工編號、姓名、職位、入職日期等。
• 唯一性和標識列：通常會有一個或多個列來唯一標識每一行，這被稱為主鍵（Primary Key）。主鍵的值在表中必須是唯一的，不能重複，並且不能為 null。例如，在員工資訊表中，員工編號列可能被指定為主鍵，這樣透過員工編號就能唯一地確定一名員工的記錄。

列（Columns）

• 資料屬性的定義：列定義了資料的屬性和型別。每個列都有一個名稱和相應的資料型別，資料型別決定了該列可以儲存的資料的種類和範圍。例如，姓名列可能是字元型（如 VARCHAR），用於儲存員工的名字；年齡列可能是整數型（如 INT），用於儲存員工的年齡；入職日期列可能是日期型（如 DATE），用於記錄員工加入公司的時間。

常見的資料型別：

• 數值型別：包括整數型別（如 TINYINT、SMALLINT、INT、BIGINT）用於儲存整數，以及小數型別（如 NUMERIC、DECIMAL）用於精確儲存帶有小數部分的數字，還有浮點數型別（如 FLOAT、DOUBLE PRECISION）用於儲存近似的浮點數。例如，在財務資料表中，金額列可能使用 DECIMAL 型別來精確表示貨幣金額。
• 字元型別：有定長字元型（如 CHAR）和變長字元型（如 VARCHAR）。VARCHAR 型別比較常用，它允許儲存長度可變的字串，如在使用者表中，使用者名稱列可以使用 VARCHAR 型別來適應不同長度的使用者名稱。另外，還有 TEXT 型別，用於儲存大量的文字內容，如文章內容、評論等。
• 日期和時間型別：包括 DATE（儲存日期）、TIME（儲存時間）、TIMESTAMP（儲存日期和時間）等。例如，在訂單資料表中，訂單日期列可以使用 DATE 型別，而交易時間戳列可能使用 TIMESTAMP 型別來記錄精確的交易時間。
• 布林型別（BOOLEAN）：用於儲存真（TRUE）或假（FALSE）的值，如在使用者許可權表中，用於表示使用者是否具有某種許可權。
• 二進位制型別（如 BYTEA）：用於儲存二進位制資料，如圖片、檔案等的位元組流。不過在實際應用中，通常會將檔案儲存在檔案系統中，而在資料庫中僅儲存檔案的路徑等相關資訊。

約束（Constraints）

• 資料完整性的保障：約束是用於確保資料表中資料的準確性和完整性的規則。它限制了可以插入、更新或刪除的資料，使得資料符合預先定義的條件。
• 主鍵約束（Primary Key Constraint）：如前所述，主鍵是唯一標識一行的列或列組合，主鍵約束確保了主鍵值的唯一性和非空性。例如，在學生成績表中，學號列作為主鍵，透過主鍵約束保證每個學生的學號是唯一的，不會出現兩個學生有相同學號的情況。
• 外來鍵約束（Foreign Key Constraint）：用於建立表與表之間的關聯關係。外來鍵是一個表中的列，它的值必須與另一個表（稱為主表）中的主鍵值相對應。例如，在一個包含學生表和課程表的資料庫中，選課表中有學生學號列和課程編號列，學生學號列是指向學生表主鍵（學生學號）的外來鍵，課程編號列是指向課程表主鍵（課程編號）的外來鍵。這樣就確保了選課記錄中的學生和課程必須是在學生表和課程表中已經存在的。
• 唯一約束（Unique Constraint）：確保列中的值在整個表中是唯一的，但與主鍵不同的是，唯一約束列可以包含 null 值。例如，在使用者表中，電子郵箱列可能有唯一約束，這樣每個使用者的電子郵箱地址在表中是唯一的，但可以允許某些使用者不填寫電子郵箱地址（即 null 值）。
• 非空約束（Not Null Constraint）：規定列中的值不能為空。例如，在員工基本資訊表中，姓名列可能有非空約束，因為每個員工都應該有姓名記錄。

索引（Indexes）

• 資料查詢的加速工具：索引是一種資料結構，它類似於書籍的目錄，用於加快資料的查詢速度。索引建立在一個或多個列上，資料庫透過索引可以快速定位到滿足條件的資料行，而不需要對整個資料表進行全表掃描。例如，在一個客戶資訊表中，如果經常需要透過客戶姓名來查詢客戶記錄，那麼可以為客戶姓名列建立索引。當執行查詢語句 “SELECT * FROM customers WHERE customer_name = 'John';” 時，資料庫可以利用客戶姓名列的索引，快速找到名為 “John” 的客戶記錄，而不是逐行檢查整個表。不過，索引也會佔用額外的儲存空間，並且在插入、更新和刪除資料時，需要維護索引結構，因此需要合理地建立和使用索引。