資料庫，是『必要』抑或『想要』？

本章探討「資料庫」存在的意義，從而了解為何會需要資料庫的幫助。
針對當前的使用情境，如何判斷「建置資料庫」是『必要』抑或『想要』？

資料庫

"A database, meaning a structured way to store and access data." -- MongoDB University [M001] MongoDB Basics

「資料庫」是結構化的資訊以電子化的方式，井然有序地儲存在電腦系統的集合。 -- ORACLE Website

「資料庫」一詞之所以出現，是因為當 持續、大量且相關的『資料』 撲面而來時，我們需要有一個 統一儲存並管理的『場所/系統』 。因此，「資料庫」以及「資料庫管理系統 （DBMS）」應運而生。

透過電腦軟體（即 資料庫管理系統 DBMS）的協助，組織化、結構化地管理我們的資料，從而方便我們對資料進行新增、修改、刪除、查詢的動作。

This means that you’re storing your data in an organized way. 🗂️

總之，資料庫的存在意義是為了井然有序地儲存資料（Storing），並且便於我們快速查找所需的資料（Querying）。

「建置資料庫」是否有其『必要性』？

根據實務經驗，我認為如果經常遇到下列的工作場景，就應該開始考慮建置資料庫，來減輕自身的工作負擔，以及改善組織的工作流程。

情境一：公司內部資料不互通且更新不即時

假如你所負責的任務內容與多個部門的產出密切相關，且需要即時掌握資料傳遞的動向或是資訊內容的更新，那麼擁有一個統合管理各部門產出成果的資料庫就顯得格外重要。

理由如下：

1. 各部門自己掌握的資料，往往其記錄方式只有自己人看得懂（極可能簡略地 key-in 至 Excel）。 因此，假如需要調資料的話，在沒有建立資料庫的情況下，必須仰賴特定部門人員人工查找 Excel，相當費時耗工。
2. 資訊上的即時更新，仰賴各部門間人與人的通知，這相當考驗人性。 若是發生忘記通知或溝通不良的情況，那麼就慘了…
3. 假如希望在不建置資料庫的情況下，藉由增設一個專責人員來處理「資料傳遞的動向」和「資訊內容的更新」這樣的任務，也不是不行。只不過，若是幾十或幾百筆資料的主動詢問和隨時追蹤或許還行，但…成千上萬筆的話，可是會做到厭世的呀！更別說，出錯的機率也會大大提高。😱😱😱
4. 假如公司不斷成長壯大，部門人數漸漸變多，那麼資訊不對稱的問題就會漸漸浮上檯面 ，光是確認並取得完整且正確的資料內容就疲於奔命了

然而，若是擁有一個統合管理各部門產出成果的資料庫，一切便迎刃而解。🍻

由於匯入資料庫的資料已經整理也通過正規化，而且各部門成員有權限即時更新資料，這大大提升使用者在查詢資料上的便利性和可解讀性。

場景二：人工查詢多張資料表的關聯結果，加重工作負擔

想像一下，你是一個負責資料管理的小小螺絲釘，每天有數十筆、甚至是數百筆的資料存取或查詢需求等著你一一回覆。

而你的面前出現兩條路可選擇：

1. 【無建立資料庫】
   將各部門的多種表格資料，以人工方式彙整成一份 Excel 後，再開始一一處理成千上百的資料請求。
2. 【有建立資料庫】
   使用資料庫查詢語言（如：SQL），藉由下指令查詢的方式，直接回傳查詢結果以應付成千上百的資料請求。

你會選擇哪一種方式呢？ 🧐

當然是選擇最輕鬆且避免人為因素出錯之『藉資料庫查詢語言直接檢索出結果』的方式呀！😎

雖然人工彙整成 Excel 後再用眼睛一個個檢索也行，但彙整的過程實在太過浪費時間，且每次更新就必須重新製作一份 Excel。
哎… 想想就心累～ 😨😨😨

除此之外，處理過程中難保你不會不小心修改到其他部門提供 Excel 裡面的紀錄，或是因人為因素而拿到非最新版的資料。

因此，藉由資料庫查詢語言（如：SQL）進行多種資料表之間的關聯查詢，是最有效的解方，還可應付未來更大量的資料請求的需求，減輕個人的工作負擔！👍👍👍