開源電子商務軟件市場已經歷了眾多發展階段，您可能已經通過 osCommerce、Magento、Zen Cart、PrestaShop、Spree 等流行平台而有所了解。這些平台經常用作定制電子商務軟件的基礎，都要求使用一個 SQL 數據庫。由於開源軟件在適應定制功能時存在固有的挑戰，現在看來 MongoDB 將在電子商務的下一輪發展進化中扮演着重要角色。
Kyle Banker 是 2010 年 4 月第一批就 MongoDB 和電子商務 發表博客的人，自那以后就令人意外地很少出來此類文章。在博客中，Kyle 寫到了 Magento 及其他基於 SQL 的平台：“您將看到的是，大量表格共同作用，在數據庫系統基礎不太靈活的型式上提供靈活的結構。”
對此我們必須問，靈活的結構在電子商務中為什么如此重要？
開源平台意味着可以適應許多不同的設計、折算流和商業流程。靈活的結構可以通過為開發者提供一種將自定義數據結構與平台現有模型相關聯的方法，從而帶來幫助。如果沒有靈活的結構，開發者就必須跨越重重障礙來實現某種特殊功能。當建立和維持自定義功能的成本過高時，可以作出的選擇有：放棄功能，以另一平台重新開始，或按草案建立一個平台。這些都是昂貴的提案。
還有更好的方法
過支幾年來，我們一直在開發 Forward，這是一種與 MongoDB 相配合的新開源電子商務平台 。自 2012 年 3 月以來，它就已經投入了生產使用中，並最終印證了一點，即我們可以展示 MongoDB 的無結構設計為自定義功能開發帶來的優勢。
以下示例展示了 Forward 與其他平台類似的 ORM 慣例，它僅在平台本身中提供，但其基本理念直接映射到了 MongoDB 的文件結構。在此情況下，考慮將 get() 作為 db.collection.find() — put() 作為 insert/update() — post() 作為 insert() — delete() 作為… delete()。
更快原型化
大多數電子商務網站都代表着小公司，在這里，高效執行是網絡平台的最重要方面。當 MongoDB 的靈活文件結構通過平台的模型界面執行時，添加自定義字段變得比以往任何時候都更簡單。
例如，讓我們假設您需要一種在向產品中添加多項自定義屬性時進行管理的簡單視圖。下面是為實現該目的的基本示例，以 Forward 的模板語法編寫：
{args $product_id}
{if $request.post}
{$product = put("/products/$product_id", [
spec => $params.spec,
usage => $params.usage
])}
{flash notice="Saved" refresh=true}
{else}
{$product = get("/products/$product_id")}
{/if}
<for method="post">
<div class="field">
<label>Product specification</label>
<textarea name="spec">{$product.spec|escape}</textarea>
</div>
<div class="field">
<label>Product usage instructions</label>
<textarea name="usage">{$product.usage|escape}</textarea>
</div>
<button type="submit">Save product</button>
</form>
該模板有什么作用可能很明顯，但不明顯的是平台對於 “spec” 或 “usage” 字段一無所知，但對待它們的方式卻好象電子商務數據模型專為它們而設計。數據庫完全無需遷移，只有代碼需要。
您可能反駁稱，這可以通過模糊 SQL 數據庫結構來實現，您也可能是對的，但它對於標准數據庫工具來說不完美，或者說無法讀取。在自定義字段上的 Ad-hoc 查詢會變得很困難。
自定義字段上的查詢
如果我們所需要的是自定義密鑰/價值存儲，那么您可能不會從靈活結構中受益太多。MongoDB 真正耀眼之處是其在任何文件字段（甚至包括嵌入式文件）上查詢的能力。
{get $oversized_products from "/products" [
oversized => true,
active => true
]}
這里有 {$oversized_products.count} 活動的超大產品
這些字段可能也可能不為電子商務 API 所知，但在此情況下，MongoDB 的查詢語法只能找到具有匹配字段的文件。
不再有關系復雜性
對於那些花費數年時間編寫關系 SQL 查詢的人，這是一大改變。沒有連接我們如何創建數據關系？有很多種不同的戰略，但 Forward 將一個字段定義為靜態值或回撥方法。這允許一個字段根據查詢返回另一個文件或集合。結果便是一個能夠無需連接便瀏覽關系的數據模型。例如 (PHP)：
// class Accounts extends AppModel
...
$this->fields => array(
...
'orders' => function ($order) {
return get("/orders", array('account_id' => $account['id']));
}
);
該關系可用以類似以下的模板中：
{get $account from "/accounts/$session.account_id"}
您已處理
<table>
{foreach $account.orders as $order}
<tr>
<td>#{$order.id}</td>
<td>${$order.sub_total}</td>
<td>${$order.grand_total}</td>
<td>{$order.items|count} item(s)</td>
</tr>
{/foreach}
</table>
關系可通過簡單或復雜的查詢來定義。結果為延遲載入，使該示例成為可能：
{get $order from "/orders/123"}
{$order.account.name} placed {$order.account.orders.count} orders since {$order.account.orders.first.date_created|date_format}
// Output: John Smith placed 3 orders since Jun 14, 2012
事務怎么樣？
許多人提出 MongoDB 在集合中缺少原子性事務作為證據，不適合電子商務應用。迄今為止，這一直不是我們經驗中的重要障礙。
還有其他方法可以實現數據完整性。在具有中低數據沖突的系統中，樂觀鎖很充分。我們會在隨后分享有關這些戰略的更多細節。
總結
有了 MongoDB，電子商務軟件的未來一片光明。是時候另辟蹊徑了，回旋式結構、復雜關系查詢和令人恐懼的數據庫遷移都已成為過去。如果您有興趣在公開發布之前與 Forward 合作，請考慮 加入私人測試 ，幫助我們令開源電子商務再度重現世界原本知道的狀態。
來自開發者/創建人 Eric Ingram 的訪客帖，請跟隨 @getfwd