點擊上方的語言選單以切換語言

回本GitHub Pages專案首頁

資料庫種類與功能說明

1. 關聯式資料庫 (Relational Database)

以表格形式存資料,強調資料一致性 (ACID)。適合金融、訂單、ERP 系統。

資料庫 功能/特點
MySQL 開源、支援 SQL 查詢、適合中小型網站
PostgreSQL 支援複雜查詢、ACID、擴展性強
Oracle Database 企業級關聯式資料庫,強一致性、穩定可靠
Microsoft SQL Server 企業應用、整合微軟生態系統

2. 分散式 / NoSQL 資料庫

資料分散在多台伺服器,支援高並發與水平擴展,部分資料庫採用最終一致性。

資料庫 功能/特點
MongoDB 文件型資料庫 (Document DB),適合存 JSON 結構資料
Redis 快取資料庫,支援即時訊息、排行榜、計數器
Cassandra 高可用、分散式,適合大數據與高流量應用
DynamoDB AWS 提供的 NoSQL,易水平擴展、免維護伺服器
TiDB 分散式關聯式資料庫,支援 SQL 與水平擴展

3. 遊戲開發中的資料庫應用場景

根據遊戲規模與營運需求,開發者會選擇單一或混合式的資料架構:

遊戲規模 資料存儲方案 應用細節 核心目的
純單機遊戲 Local Storage / 存檔文件 .json, .dat 或 SQLite 存於玩家本機。 零延遲、無需伺服器成本。
多人 / 雲端服務 混合架構 (SQL + NoSQL) SQL: 帳號、課金、商城交易。
NoSQL: 好友清單、即時訊息。
確保交易安全並提升社交互動速度。
大型開放世界 (MMO) 複合架構 (SQL + Redis + 快取) SQL: 核心數據存檔。
Redis: 全球排行榜、玩家坐標快取。
在高並發下維持數據一致性與讀取效能。
[Image of basic client-server game architecture]
架構思維: 在遊戲實務中,「混合架構」是業界標準。我們利用 SQL 的 ACID 特性保護玩家資產(如虛擬貨幣),利用 Redis 的記憶體讀取特性處理每秒數萬次的戰鬥狀態更新。

4. 資料庫正規化實戰:以主角群設定為例

正規化是整理資料結構的方法,目的在於減少冗餘、避免更新異常。以下透過德古拉、伊索爾德、芙蕾亞的資料演釋正規化過程。

初始狀態 (未正規化 - 0NF)

將所有生理屬性與多項能力塞入同一表,導致欄位違反原子性,且產生大量重複資訊。

-- 冗餘嚴重且無法有效查詢 CREATE TABLE Characters_Raw ( Name VARCHAR(20), Species VARCHAR(20), Abilities TEXT, -- "變形, 催眠" (多值依賴) Weaknesses TEXT, -- "陽光, 銀製品" CanSweat BOOLEAN, HasFertility BOOLEAN );

第一正規化 (1NF) - 原子性 (Atomicity)

確保每個欄位不可再分。將德古拉的多項能力拆分為獨立紀錄。

CREATE TABLE Characters_1NF ( CharacterID INT, CharacterName VARCHAR(20), AbilityName VARCHAR(50), PRIMARY KEY (CharacterID, AbilityName) );

第二正規化 (2NF) - 消除部分依賴

確保非主鍵欄位完全依賴於主鍵。將角色基本資料與能力表拆分。

-- 角色主表 CREATE TABLE Characters_2NF ( CharacterID INT PRIMARY KEY, CharacterName VARCHAR(20), Height_cm INT, BirthPlace VARCHAR(50) ); -- 角色能力表 CREATE TABLE CharacterAbilities_2NF ( CharacterID INT, AbilityName VARCHAR(50), PRIMARY KEY (CharacterID, AbilityName) );

第三正規化 (3NF) - 消除傳遞依賴

非主鍵欄位不可依賴於其他非主鍵欄位(角色 -> 物種 -> 生理特徵)。

-- 1. 物種生理定義表 CREATE TABLE SpeciesPhysiology ( SpeciesType VARCHAR(20) PRIMARY KEY, CanSweat BOOLEAN, CanExcrete BOOLEAN, -- 是否排泄 HasFertility BOOLEAN ); -- 2. 角色表 CREATE TABLE Characters_3NF ( CharacterID INT PRIMARY KEY, CharacterName VARCHAR(20), SpeciesType VARCHAR(20), FOREIGN KEY (SpeciesType) REFERENCES SpeciesPhysiology(SpeciesType) );

第四正規化 (4NF) - 消除多值依賴

芙蕾亞為例:將互不相關的多值資訊(技能與弱點)徹底拆分,避免無意義的資料組合爆炸。

-- 1. 角色技能表 (芙蕾亞有跆拳道、空手道等) CREATE TABLE CharacterSkills ( CharacterID INT, SkillName VARCHAR(50), PRIMARY KEY (CharacterID, SkillName) ); -- 2. 角色弱點表 (德古拉與芙蕾亞的弱點清單) CREATE TABLE CharacterWeaknesses ( CharacterID INT, WeaknessName VARCHAR(50), PRIMARY KEY (CharacterID, WeaknessName) );

第五正規化 (5NF) - 投影連接正規化

處理三方循環關聯(角色、物種、特定環境加成),確保資料拆分後可無損還原。

5. 結論:開發者的技術權衡 (Trade-off)

「過度正規化會增加 JOIN 的運算開銷,影響讀取效能。」

在實際開發中,我們通常遵循 3NF / 4NF。但在處理高頻率讀取的即時數值時,會適度採用反正規化 (Denormalization),以空間換取時間,確保遊戲運行流暢。

分享到 Facebook | 分享到 Line | 分享到 X