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}


Product specification
{$product.spec|escape}


Product usage instructions
{$product.usage|escape}

Save product


　　该模板有什么作用可能很明显，但不明显的是平台对于 “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"}

　　您已处理


{foreach $account.orders as $order}

#{$order.id}
${$order.sub_total}
${$order.grand_total}
{$order.items|count} item(s)

{/foreach}


　　关系可通过简单或复杂的查询来定义。结果为延迟载入，使该示例成为可能：

{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如何简化电子商务