對關係型資料庫侷限性的重新思考

在Nosql的歷史上有很多曲折反覆，所有曲折程式和定義不明確算所帶來的最不幸的一部分，就是失去了一些很有價值的東西。這篇帖子不是關於Nosql定義的不同，而是表明所有被歸類為專屬於無模式的的資料庫世界中的巨大好處，也可以輕鬆應用到關聯式資料庫世界中。

忘掉遷移
也許關於提到無模式資料庫最大好處就是你只要一提交程式碼就它可以很好的工作。大約五年前Heroku釋出 git push heroku master部署平臺讓你可以輕鬆的在git上面提交程式碼並讓他工作，CouchDB 和 MongoDB在資料庫方面做了樣的事情。在你在資料庫上工作時你沒有必要執行 CREATE TABLE 或 ALTER TABLE進行遷移。你只要構建和釋出你的程式而不用擔心資料遷移是多麼棒的事情啊。

這經常被看做是關聯式資料庫的一個侷限，然而其實沒有必要。你可以看到即使在無模式的資料庫中關係依然存在，只是你在應用層操作管理它。說在更高的框架層次或使用ORMs無法處理資料遷移過程是沒有道理的。在今天，在沒有引入當機時間和可以讓開發者更快的遷移沒有自動拷貝的資料的意義上，給關聯式資料庫新增一個欄位的過程還是很簡單的。

Rails/Django(你選用的框架)已經注意到讓資料列存在的需求，適當的修改後你可以在你程式碼中像管理文件關係一樣的方式使用它，當然這是一個共同的讓人懊惱的的過程，但是說它不能被PostgreSQL完全處理和在ORM中不能直接處理它是沒有道理的。

文件

其他一個強有力的說明例子是針對與MongoDB/CouchDB陣營的文件儲存，在這個例子中我將給出文件直接轉換為JSON物件的替代方案。JSON在移植性方面是一種很棒而又簡單的資料模型，但在應用層你必須要轉換它卻也是一件很痛苦的事情。是的你看到的沒錯，Postgres現在有個JSON資料型別，而且JSON資料型別也不斷的被一些其他的關係型資料庫所採用。當我沒有奢望她在JSON上的改進時， DB2對JSON的支援有點令我吃驚

在資料列中存在JSON 格式是很有意義的，在你想把所有的結果當做整體JSON物件的時候，作為完全的JSON儲存還是有點限制。Postgres 的一大買點就是你只用一個儲存過程row_to_json就可以把一整行轉換為JSON物件。

還有就是你有一些高層框架可以利用，在它們的支援下，你可以一邊讓那些強型別的資料表存在，但一邊你可以靈活地將他們對映到JSON物件，這樣是很有意義的。

出箱即用的介面

這不是無模式資料庫的專屬特性，無模式的資料庫中一些比如Couch 開箱即用特性多一點，另一些少一點。曝露一些rest 風格的介面的概念並不是新創的，不久前已經在關聯式資料庫上實驗過了。一些事情顯然需要重申一下，這個例子清楚的表明，在重新構建操作介面和降低新手的入職門檻方面，確實降低了時間。

不幸地是，現在對於Postgres 或其他關聯式資料庫，並沒有十足的進展。相反地其他資料庫從一開始就提供這些介面。

何去何從

在無模式資料庫或其他更廣泛的資料庫中，這種轉變並不是很大，它們沒有納入更多的選擇。然而同時這種轉變有很多益處，最顯著的一個就是，對傳達怎麼擴充套件所謂的”關係型資料庫”產生了積極的影響。