面對資料存取，跳脫思考的陷阱

資料的存取幾乎可以說是所有應用程式都會涉及的議題。

針對在主記憶體中處理資料的存取，我們從資料結構的教科書上學到許多資料結構，像是linked list、hash table、tree、……等等。每種資料結構都有它的用途，針對不同的目的及操作，也都會在時間、空間效率上展現出不同的特性。而優秀的程式設計者也都多半能熟練的掌握這些不同的資料結構，將它們運用在合適的地方。

關聯式資料庫興起，開發人員不像過去經常自己設計檔案結構
然而，對大多數的程式而言，不僅只會在主記憶體中操作、存取資料，另一方面，由於主記憶體容量受限、而且無法永續儲存資料的關係，程式還是會有將資料儲存在具永續性儲存能力之檔案系統上的需要。

而當將資料儲存在檔案系統，基於各種不同的應用及需求，所衍生出來的議題十分繁多。在多年前，許多程式設計者甚至會自己設計在檔案系統中用來儲存資料的檔案結構，用以滿足自身程式的需求。當然，在資訊科學的研究中，也有各種檔案結構用來提供資料應用程式之所需。就和在主記憶體中運用資料結構一樣，程式設計者也會針對各種檔案結構的特性，妥善運用各種檔案結構。

不過，這樣的現象在關聯式資料庫逐漸普及之後，由於關聯式資料庫的威力強大、可以涵蓋各種應用，對於應用程式中所需的各種操作，也都足以應付。

關聯式資料庫技術精進，不論是在資料量、存取效率、穩定度、容錯能力、等等，都大大地讓多數程式設計者得到滿足。

慢慢的，在很大比例的應用程式開發中，幾乎都採用關聯式資料庫技術來做為永續性的資料儲存方案，這說明了關聯式資料庫技術有多麼的普及、以及有多麼的受到程式設計者的喜愛。但最後，這似乎成了一個既定的刻板印象及想法，甚至構成了一個思路的陷阱，當程式設計者打算將資料儲存起來的時候，幾乎都會直接聯想到關聯式資料庫。不論什麼樣類型的資料，都把它們一筆筆地往關聯式資料庫裡丟。

正因為關聯式資料庫太強大、能應用的範圍也很廣泛，所以運用它來解決永續性的資料儲存，可以說是十分的便利，在一般的情境下，也都能勝任愉快。不過，這麼一來，也很容易建立起程式設計者對它的依賴。

我也觀察到一個現象，不少程式設計者對於其他永續性資料儲存方案的運用能力，似乎都退化了不少。剛入行的程式設計者甚至不懂得、或者是不熟悉如何運用其他永續性的資料儲存方案。在一般承平時期，關聯式資料庫足堪應付時，這樣的情況還不至於造成太大的問題。但是，倘若碰上了障礙，也就是關聯式資料庫本身不那麼適合處理的應用時，有些程式設計者，反而不知道該如何面對這樣的障礙。

事實上，有時候改用不同的儲存方案來處理特定的問題，反而會比千篇一律地採用關聯式資料庫來得適合。

關聯式資料庫也有不適合應用的時候
舉例來說，有些時候，我們要存取的資料，每筆資料都有固定的欄位，但是，這些欄位不會需要和其他資料的欄位交互關聯，也只有一個鍵值。而在應用程式中，只需要新增資料、指定鍵值對資料進行查詢及刪除。針對這個應用，當然，你可以在關聯式資料庫中建立一個資料表，然後利用這個表格來儲存這樣的資料。強大的關聯式資料庫要處理這樣的資料當然不成問題，資料很單純、需要的操作也很單純。

正因為其實要面對的問題很單純，但使用的工具很強大，就成了殺雞用了牛刀的局面。牛刀能殺牛，但用來殺雞就顯得有點不稱手。當你用強大的關聯式資料庫來處理需求很簡單的資料時，強大的威力反而變成了絆腳石。

關聯式資料庫的設計，是為了要滿足各種複雜的關聯式查詢及資料處理，因此，在機制上自然是相當的複雜。而在這樣複雜的機制下，去處理簡單的資料，即使資料本身再怎麼簡單，在效率上也會大打折扣。

如果你的應用程式大多數的操作是依據主鍵值，查出對應的該筆資料，你當然可以執行一個SQL查詢的動作，把對應的資料查詢出來，這對威力強大的關聯式資料庫而言，根本是探囊取物一般。可是，即使是這樣簡單的查詢，遇到資料量龐大時，這個查詢還是會耗費不少時間。

這並不是牛刀不夠厲害，而是牛刀有該用牛刀的地方。

針對這樣的應用，你也可以改用像Berkeley DB之類的解決方案。

Berkeley DB不像典型的關聯式資料庫那樣強大，當然就不那麼的複雜。處理起這樣的資料，可以說是適得其所，而且更為高效。

這正是許多程式設計者目前在永續性資料處理上的一個盲點。

因為關聯式資料庫搭配SQL語言的強大，讓程式設計者過度依賴關聯式資料庫，反而失去了運用其他類型資料管理方案的能力。倘若只侷限在關聯式資料庫的基礎上，而又遭遇了效能問題，想要加以調校以提升效能，就得大費手段。但是，若能跳脫只能在關聯式資料庫的基礎上解決這個問題的限制，反而容易多了。

混合運用其他資料存取方式的可能性會增加
可以想見的，關聯式資料庫依然會是一個主要的資料儲存平臺，但是，針對特定類型、特定需要的資料操作，我們可能會混用其他較關聯式資料庫更適合的資料管理方案。

最近許多人在談所謂的NoSQL資料儲存方案，當然這NoSQL字面上的意思是代表非SQL語言，不過本質上指的其實是非關聯式的資料庫。我觀察到，大多數會開始採用NoSQL方案的開發者，基本上都是因為資料規模的關係。

關聯式資料庫很好用，但它不容易擴展到很大的規模。因此，許多開發者逐漸開始運用所謂NoSQL資料庫來儲存所謂「海量」的資料，而一些雲端計算平臺，也都以此類的資料儲存方案，來做為平臺供應用程式處理資料的機制，都是為了面對大規模的資料量所做的應對。

而且，許多NoSQL的方案都提供分散式的機制，允許將大批機器的計算能力及儲存能力群集起來，提供允許超大規模的資料高效存取。
當然，本文的主旨並不在說NoSQL的卓越及關聯式資料庫的落伍，而是試著提醒，資料儲存及處理是應用程式中的重要操作，關聯式資料庫固然強大，但內部複雜的運作方式，也構成了一些本質上難以突破的先天障礙。

我們或許已經習慣於總是將資料都交給關聯式資料庫來承載，而忽略了應該針對資料本身及所需操作的特性進行分析，進而在適當的時機，選用關聯式資料庫之外的方案來處理資料。你或許不會需要用到處理海量級的分散式NoSQL方案，你有可能選擇的是像Berkeley DB之類輕薄短小的資料庫，端視你的需求而定。甚至你可以自己設計自己的資料儲存機制。

跳脫總是從關聯資料庫出發的慣性觀點，你會發現，選擇上還有很多，而且重要的是，更符合你的需要。