MongoDB 如何使定製電子商務變得簡單

開源電子商務軟體市場已經曆了眾多發展階段，您可能已經通過 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

 

原文：MongoDB如何簡化電子商務