網站資料庫設計是什麼？5 個規劃重點提升後台資料管理效率

網站資料庫設計是什麼，為什麼一個看不見的東西，會影響您每天在後台花多少時間？常有客戶來諮詢時提到，網站才上線兩年，後台卻越用越不順手，商品分類越加越亂，想多記一個欄位還得請工程師改程式。聽完我們通常會先問一句：「當初建站時，有人跟您討論過資料要怎麼放嗎？」多數時候答案是沒有，資料怎麼放，常在建站時被當成工程師的事，一筆帶過。

網站資料庫常見問題有哪些？

網站資料庫最常見的問題有三個：資料分類混亂、後台查找不方便、功能擴充受限制。這三件事多半在上線一兩年、資料累積起來之後才浮現，源頭大多在建站初期少了一步資料規劃。

1. 資料分類混亂

商品越賣越多是好事，分類跟著長出來也很自然。麻煩在於沒有共同的規則，每個人依自己的習慣新增，同一個商品可能同時掛在「新品」「熱銷」「2024春季」三個分類，沒有人說得清哪個才是主分類。久了，後台就像一間沒有標示的倉庫，東西都在，要找的人只能一格一格翻。

資料分類一亂，前台也會跟著受影響。訪客點進某個分類，看到的商品缺東缺西，對品牌的印象就少了一分。這份分類規則其實在建站階段就能先訂好，後面接手的人照著走就好。

2. 後台查找不方便

客人打電話來問訂單，您在後台要花多久才找得到？

常見的狀況是只能打完整名稱搜尋，資料一多就只能一頁一頁往下滑。背後原因多半出在資料庫欄位沒有規劃好，例如訂單日期存成一般文字，系統就沒辦法依日期區間篩選；會員電話有人加連字號、有人沒加，搜尋時就會漏掉。前台看起來一切正常，時間成本全壓在管理後台的人身上。如果同事每天都要花半小時「找資料」，就很值得回頭檢查一次。

3. 功能擴充受限制

生意做起來之後，想在網站加預約功能、做會員分級，是很自然的下一步。這時如果廠商回您「要整個重做」，功能擴充會卡住，多半是因為當初的資料庫只照著「現在」設計。會員資料只記了姓名和電話，點數、等級都沒有地方放；有些套版系統的資料結構是固定的，能調整的範圍更小。

等到要擴充才回頭改結構，就像房子蓋好了才想加一間房，牽動的是整棟的管線。挑系統時先問清楚「日後加功能怎麼加」，能省下不少回頭重做的時間。我們在客製化網站與套版網站的差別這篇也整理過這類比較。

網站資料庫規劃要注意什麼？

網站資料庫規劃要注意5件事：確認資料類型、規劃欄位結構、設定資料關聯、保留擴充彈性、對應後台操作需求。想弄懂網站資料庫設計是什麼，順著這5個重點由內而外看最清楚，先想好資料本身，再對應到管理的人怎麼用。

1. 確認資料類型

規劃的第一步，是把網站要管的東西列出來。形象官網多半是產品、最新消息這類內容資料；電商網站則多了會員、訂單這類每天都在變動的交易資料。每種資料類型的性質都不同，有的幾乎不會變，像公司簡介；有的每天都在增加，像訂單；有的會被很多頁面引用，像產品。先分清楚，後面才知道哪些要獨立管理、哪些可以合併。

這份清單不必一次列到完美，最好在簽約、動工之前，就跟網站廠商一起過一遍。

2. 規劃欄位結構

資料類型確定後，接著要決定每筆資料記錄哪些「欄位」。欄位可以想成表格裡的每一個直欄，產品資料裡的「名稱」「價格」就各是一個欄位。

欄位規劃常見的疏漏有兩種。一種是欄位太少，上線後才發現沒地方放英文品名或保存期限；另一種是格式沒定好，價格存成文字、日期各寫各的，後台就沒辦法排序和篩選。規劃時一併決定每個欄位「必填還是選填」「用什麼格式」，資料品質會穩很多。最簡單的做法，是拿現有的Excel或紙本表單來對照，您平常記錄哪些項目，資料庫就該有對應的欄位。

3. 設定資料關聯

同一個門市地址，您的網站上是不是有三個頁面各存了一份？

設定資料關聯，就是讓一份資料只存一次，其他地方用「引用」的方式取用。訂單不必重複記錄會員的姓名電話，只要記下是哪一位會員；產品只要標記屬於哪個分類，分類名稱一改，所有產品跟著更新。這種做法背後的觀念，就是關聯式資料庫模型，1970年由IBM研究員科德（Edgar F. Codd）提出，至今仍是多數網站資料庫的基礎。

關聯設定好，改一處、全站同步，就不會發生首頁寫舊地址、聯絡頁寫新地址的尷尬。

▌延伸閱讀：關聯式資料庫模型的起源與基本概念（維基百科）

4. 保留擴充彈性

資料庫規劃得再完整，也只能照顧到「現在想得到」的需求，替未來留點擴充彈性，日後會輕鬆很多。

AWS官方部落格在2019年10月宣布，Amazon消費者業務完成一次大規模的資料庫搬遷。這個業務原本大量使用Oracle資料庫，隨著生意成長，團隊決定依資料用途，把資料分到不同類型的資料庫，前後動員100多個團隊，搬移約75PB資料與近7,500個資料庫。完成後，資料庫成本降低60%以上，管理工作量減少70%。

中小企業的網站規模小得多，道理相通。資料的用途會跟著生意改變，規劃時預留可新增的欄位與分類、選一套能彈性調整的系統，日後擴充就不必整批搬家。這也是米洛採用模組化系統的原因，底層架構穩定，上層再依您的資料與作業流程調整，要加功能時也有地方接得上。

▌延伸閱讀：Amazon完成資料庫搬遷的官方說明（AWS部落格）

5. 對應後台操作需求

資料庫最後是給人用的，所以規劃時最後要問一題，每天是誰在後台操作，他們最常做什麼？

客服最常查訂單和會員，行銷最常更新文章與活動，兩邊需要的查詢方式和可修改範圍都不一樣。把這些日常動作回推到資料庫，就會知道哪些欄位要能被搜尋、哪些內容只開放特定人修改。這一步做好，後台用起來才會順手。

5個規劃重點看完，可以用這張表做個總整理。它補上前面沒細談的兩件事，企業要先準備什麼、哪裡最容易出錯，方便您直接拿去跟廠商對照。

網站後台資料管理怎麼設計？

想讓網站後台資料管理好用，可以從三個地方下手：建立清楚分類、設計搜尋與篩選、規劃新增與編輯流程。目標很單純，讓管理的人少花時間找資料，也少改錯資料。

1. 建立清楚分類

後台的分類，決定管理者打開後台的第一眼能不能找到方向。清楚的後台分類可以守住三個原則。第一，同一層用同一個標準切，例如都用「產品用途」，就別混進「新品」「特價」這類行銷標籤；第二，層數控制在兩到三層，太深的分類要點好幾下才找得到；第三，活動需要的彈性分組，另外用「標籤」處理，跟主分類分開。

分類規則最好寫成一頁簡單說明，新同事接手時照著維護，前台選單和後台管理都能一直保持清爽。

2. 設計搜尋與篩選

資料量一過百筆，後台有沒有好用的搜尋與篩選，差別就很明顯。

後台搜尋適合「知道要找誰」的情境，例如輸入訂單編號；篩選功能適合「想看某一群」的情境，例如本月還沒出貨的訂單。使用者體驗研究機構Nielsen Norman Group在2014年的文章提過，多條件篩選雖然好用，建置與維護成本也高，最好先確認使用者確實需要。放到後台也一樣，篩選條件跟著實際工作挑，不必每個欄位都做。

實際規劃時，可以請後台使用者列出「每週最常找的三種資料」，篩選條件就從這裡開始設計。

▌延伸閱讀：篩選與分面搜尋的差別與設計原則（NN/g）

3. 規劃新增與編輯流程

資料要好管，除了找得到，也要新增得正確、改得安心。

流程可以從三個地方設計。必填欄位加上格式檢查，例如電話只能填數字，從源頭擋掉錯誤資料；重要內容先存草稿、預覽確認後再上線；依角色設定帳號權限，客服只能看訂單、編輯只能改文章，誤改的機會就少很多。米洛的Evo後台就支援草稿儲存，以及依「角色、功能、操作」細分的權限設定，更多功能可以參考CMS後台是什麼這篇的介紹。流程順了，後台交給誰管都安心。

米洛科技推薦，協助你解決網站資料庫設計與後台資料管理問題

網站資料庫設計是什麼？說穿了，就是在網站上線前，先替資料想好住處，也想好彼此的關係。這件事看不見，卻決定了後台每天好不好用、網站日後能不能順利長大。

米洛專注網站設計與系統開發，規劃新網站時會把資料結構和後台操作一起想進去。底層用模組化系統加速開發，上層依您的資料與作業流程量身規劃，避開套版的固定框架，也省下從零開發的時間。

後台好不好用，決定的是往後每一天的工作時間。如果您正在規劃新網站，或覺得現在的後台越用越卡，歡迎讓米洛先做免費網站健檢，初步看看現況，給您前3項調整方向。

常見問題FAQ