🔧 阿川の電商水電行

Shopify 顧問、維護與客製化

💡

小任務 / 單次支援方案

單次處理 Shopify 修正／微調

⭐️

維護方案

每月 Shopify 技術支援 + 小修改 + 諮詢

🚀

專案建置

Shopify 功能導入、培訓 + 分階段交付

👉 瞭解詳情 / 免費諮詢

小編精選 - 技術文章翻譯 · 01月14日

為什麼資料庫很重要？這是一個很多人無法解釋的概念。

引言

「資料庫很重要」這句話我們常常聽到。

而資料庫為什麼在「技術上」如此重要？這個問題經查詢後很容易找到答案。

然而，從根本的思考方式和對資料庫的理解上，對於資料庫的「概念性」重要性進行闡述的人意外的少，而進行說明的難度似乎也相對較高。

因此，我想嘗試從概念性的角度，而非技術性方面，來寫出資料庫的重要原因。

如果沒有資料庫？

請稍微想像一下。你經營著一家小商店。

沒有資料庫的世界

【第1天】
來了3位顧客。我將訂單寫在便條紙上。

田中先生 → 蘋果3個
佐藤女士 → 橘子5個
鈴木先生 → 香蕉2串

【1週後】
顧客數量增加到50人。便條紙變成3本...

「嗯，先週田中先生的訂單到底在哪裡...」
（30分鐘後）「找到了！但是田中先生有2個...是哪一位？」

【1個月後】
顧客數量增至500人。

「我想發送促銷通知給所有曾經購買過蘋果的顧客」
「...除了查看每一本便條紙的每一頁別無他法...」
（3天後）「還沒做完...而且可能還漏掉一些...」

現實中發生的事情

聽起來像笑話，但這實際上是現實企業中所面臨的問題。

用Excel進行顧客管理 → 檔案損壞導致全數據消失
用紙本帳本管理庫存 → 盤點耗時
用電子郵件共享資訊 → 「那封郵件跑去哪裡了？」

資料庫能幫助解決這些問題。

資料是「程式」的壽命更長

還有許多人容易忽略的一個事實。

程式會被不斷重寫，但資料會持續存在

這是資料庫重要性的根本原因。

透過具體例子思考

【2010年】
・語言: PHP 5.2
・框架: 無（純PHP）
・顧客數據: 1萬條

【2015年】
・語言: PHP 7.0
・框架: Laravel 5
・顧客數據: 10萬條（包含2010年的資料）

【2020年】
・語言: Python 3.8
・框架: Django
・顧客數據: 50萬條（包含2010年的所有資料）

【2025年】
・語言: Go
・框架: Gin
・顧客數據: 100萬條（15年的資料依然存在）

雖然程式語言變了3次，但顧客資料從未丟失過。
這正是資料庫需要「與程式分開」進行嚴謹設計和管理的原因。

傳統的程式導向思考方式（POA : Program Oriented Approach）

在設計過程中，我們往往很容易以程式為中心來思考。

1.「要製作什麼功能？」

2.「那個功能所需的資料是什麼？」

3.「那麼，來創建這樣的資料表吧」

然而，這種思維方式在規格更改時，資料結構也會隨之改變。

資料導向的思考方式（DOA : Data Oriented Approach）

1.「這個業務中處理的"物件"或"事件"是什麼？」

2.「它們之間的關係是什麼？」

3.「設計資料結構」

4.「構建使用該資料的功能」

這種思考方式下，無論功能如何變化，資料結構都不會改變。
開發過程中，規格變更是無法避免的。

回過頭來看，圍繞資料的思考往往能讓開發進展變得更順利，現在DOA被認為是主流的做法。
實際上，我們常常聽到「資深工程師如何圍繞資料中心展開開發」的相關討論。

資料的具體例子

例：電子商務網站的設計

-- 使用DOA設計的話，會形成如下簡單的結構

顧客（顧客ID, 姓名, 郵件地址, 地址）
商品（商品ID, 商品名稱, 價格, 庫存數）
訂單（訂單ID, 顧客ID, 訂單日期, 總金額）
訂單明細（訂單ID, 商品ID, 數量, 單價）

如有這樣的結構，無論什麼功能都能得到支持：

「想增加積分制度」→ 在顧客表中增加積分欄
「想要增加定期購買功能」→ 增加定期購買表
「想要增加評論功能」→ 增加評論表

只要資料結構穩固，新增功能就不再可怕。

資料庫是「約定」

接下來將討論一些抽象的事情。

資料庫的資料表定義（模式）不僅僅是一個技術設計圖。它是 「在這個系統中，如何理解現實世界的一項聲明」。

例：「顧客」的定義

CREATE TABLE 顧客 (
    顧客ID INT PRIMARY KEY,
    姓名 VARCHAR(100) NOT NULL,
    郵件地址 VARCHAR(255) UNIQUE,
    生年月日 DATE,
    會員等級 VARCHAR(20) DEFAULT '一般'
);

這個定義在全公司範圍內作出了以下約定：

定義	意味的約定
`顧客ID INT PRIMARY KEY`	「顧客必須能唯一識別」
`姓名 NOT NULL`	「沒有姓名的顧客將不存在」
`郵件地址 UNIQUE`	「同一郵件地址不可註冊兩位顧客」
`生年月日 DATE`	「生年月日必須為正確的日期格式」
`會員等級 DEFAULT '一般'`	「所有新註冊的顧客皆為一般會員」

為何這是「約定」的理由

業務部：「我們將依此規則註冊顧客」
開發部：「我們將根據此規則開發系統」
客服部：「我們將依此規則查詢顧客資訊」

資料庫設計是一個超越部門的約定。

「真實的單一來源」這一概念

有一個英語概念稱為 "Single Source of Truth"（SSOT）。

「對於某一資訊，正確的值應該只有一個地方」

這是資料庫所扮演的最重要角色之一。

反模式：真實信息多頭者的地獄

Excel檔案「顧客名單_最新.xlsx」 → 業務部管理
核心系統的資料庫 → IT部管理
Google試算表「顧客備註」 → 客服中心管理

如果資料以這種方式進行管理的話

「聽說田中商事的地址變了」
「嗯，應該去更新哪裡呢？」
「全部...？」
「等等，業務部的Excel中還是舊地址...」

這是企業中實際發生的事情。

為什麼這是個問題

【1個月後的狀況】

Excel地址 : 東京都澀谷區... （上個月更新）
資料庫地址 : 東京都新宿區... （半年前的狀態）
試算表 : 東京都品川區... （兩年前的狀態）

真實的地址究竟是在哪裡，誰也無法辨別了。

透過資料庫解決

【正確的設計】

                ┌─────────────┐
                │ 資料庫 │
                └──────┬──────┘
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
  銷售系統    財務系統    支援畫面
  （僅供參考）    （僅供參考）    （僅供參考）

規則：