我覺得標題不行，不過沒差啦。

說到資料庫不知道大家會想到什麼 ? 對當初的我來說這完全就是一個陌生的東西。
人生唯二對DATA有印象跟接觸的，那大概就是，星艦迷航記 NEXT GENERATION 的Andriod 。

台灣翻譯叫做百科

就是他~~

OOPS 放錯了 好啦 這是祖克伯啦

但是真的滿像的

第二印象就是 matrix 裡面構成世界的資料數據流其實也是攻殼機動隊。

不過，這不是我要講的重點啦，重點是數據之於程式設計就好像是水資源之於自來水處理廠一般重要。

來看看 劍橋英文字典(康橋，嘿對 就是徐自摩那個)

好孩子學英文

A large amount of information stored in a computer system in such a way that it can be easily looked at or changed.

以下不負責任翻譯

【是一種將大量資料儲存在電腦系統裡面的方式，而且容易被搜尋及修改。】

畫重點，儲存大量資料，容易被搜尋及修改。

所以基本上DATABASE就是一個來儲存的東西，跟穀倉拿來儲存糧食。

書櫃拿來放書的用法是一樣。儲存，是DB的第一重點，再來就是容易被搜尋及更改。

搜尋的行為有很多需求上的因素，但是重點在於它很容易做到這三件事情。

所以DB的重點就在於儲存，搜尋，跟修改。

如果你常常爬論壇，或是對這塊有興趣，你可能會常常看到CRUD，這不是什麼特殊單字

而是一般針對DB或著說是被儲存的資料，做各種資料操作行為的簡稱。

(因為除了DB還有很多種媒介可以達成任務)

分別對應，Create 新增創造一筆資料行，READ 讀取一筆資料行，Update 修改一筆資料行 Delete 刪除一筆資料行。

不過單純講行為，絕對不是什麼難事。T-SQL (transection Structured Query Language) 簡單的結構化查詢語言概念了解的話，半個小時內就可以上手了，連阿嬤都學的會喔。

其實DB的重點著眼於規劃跟設計，我想國小大家都查過字典吧? 去圖書館找書也是依著索引下去找。或是數學在查指對數表的時候，使用上大家經過訓練都不是問題，就是依循一個關鍵值，再去對照。

但是如何設計出一個好查詢，該用什麼下去當關鍵值? 又可以快速查詢出資料的資料庫，這就是門技術了。

更進一步來說，如何把現實中存在於生活裡的各種看似沒有結構化，跟看起來鬆散沒有相關聯的人事時地物，一一加以結構化，規則化，歸納出彼此的關聯。(這裡先以關聯式資料庫為主

在這塊過程中是需要腦力激盪的，大致上就是針對DB設計的概念ACID

下去做各種整理-也就是正規化處理 normalization。當然還有其它各種的，設計理念，最主要是看你所要處理的資料特性，至於什麼叫做特性呢?

資料量是否龐大? 連續? 受查詢的次數? 與其他資料的關聯性? 商業上的性質..等等都會影響到你的DB該選用

哪種資料結構的設計。在學習的當下只覺得大開眼界，跟在視窗或console只單純把資料寫進記事本，或是記憶體中

再秀出來，完完全全是兩回事；可以說是，在這階段要追求的是一種讓資料適得其所，且方便於查詢，修改。

那時候我們基本上就在，規劃我們的專題資料庫了，我們要決定資料庫的大小，釐清資料間彼此的關聯性

再來規劃一個一個的資料表，這裡可以先提到一個東西，就是資料庫的設計很大一部分也是由使用的場景

決定的，應該說是行為上的需求。

我們組別在一開始設計上，是依需求也就是功能上去分類，大致上有點像是Domain Driven Design

這種由前到後的概念，很大一部份將主力放在了程式邏輯，DB其實只是配合使用。嚴格來說並沒有完全發揮

DATABASE，應該有的一些特異功能。也因為是by 功能需求，資料的結構特性其實相當單純。

真正用到對照的也是為了符合ACID特性去拆開的。

真正出去工作後，漸漸發現到，有些資料型態跟結構，會適合在DB設計上就去做掉他，避免在BLL的時候很麻煩。

也些東西則可以直接程式解在BLL解決，沒有好或不好，單純的是看需求跟資源上花費，還有程式的穩定度。

也就是寫程式這件事情，其實沒有所謂的最佳解，永遠都是根據你目前手邊的需求，跟你所有的工具下去尋求最穩定

也最能達成需求的解決方法，之後就是你升職，我加薪，大家開香檳，還可以玩幸運輪大抽獎。

不過，也有很大一部分的原因是，在古早的時候，DB跟程式端的記憶體都不是很足夠。

而且DB每次接受的連線數是有限制的，頻繁的開關連線，如果加上又忘記釋放連線，很常會發生 DB connection pool 不夠用的問題。

不過還是可以用DI 跟工廠的設計去處理這一塊，或是程式的語法糖。 而且ORM流行起來以後，基本上連線管理這塊，已經很輕鬆了。

只是，不管是當初授課的老師，或是職場主管跟前輩都會提醒要注意這塊。特別是所謂大型的OLTP(線上交易處理)，還是會盡量把整個流程上的loading分散開來，該給DB解的就給DB，寫很多的store procedure,trigger,function來在DB端處理。把程式端的資源留下處理比較複雜的邏輯，跟單純的IO應用。

寫到這裡，我會覺得如果看到這篇文章的你，也是正在學習DB的路上，建議先搞清楚DB的使用方法。

從建立連線一路到，CRUD，怎麼用程式處理，怎麼在DB處理，先穩穩地學好。

因為，設計規畫方面這塊，也不是一蹴可幾的。如果有機會多多參與各種DB系統的設計，跟相關讀書會，多多實戰。

不停被自己打臉，這樣才可以學習得比較快，而且自己打自己，總比被別人刮耳光好啊。

另外，就像上面說的沒有最好的設計，只有當下最適當的設計。

就像我的主管說過，There are no silver bullets ,no one thing for all.

其實學習DB這塊，或著應該說學習程式這塊，很像在練武功。

易學難精，很多第一次XX就上手，或是幾小時學通XX語言，最後可能都會變成

學習XX，從入門到放棄，這個還算好的，如果沒有學精，很有可能變成從刪庫到跑路。

其實資料庫還有很大的一個重點，那就是備分，備源，甚至當你的資料消失會是不可承受之重的時候。

如何去設計一套，災難性備源的機制，還有整套復原演練的流程。以求，最短時間，不影響系統，完全復原資料。

這是門很深的學問，你可能會想會有這麼一天嘛? 我只想歷史上有很多有名的案例，像世貿爆炸，911雙塔倒塌

還有各種天災，過去是大型企業自己養SERVER會比較辛苦，這7~8年都開始上雲，跟有docker。

不過，還是有私人雲，地端這些，有沒有好的整套備援機制，我想是一個企業構不構成熟的指標之一吧。

感謝大家今天的收看，明天聊聊談需求的經驗吧