如何根据业务选择不同的技术架构，这是一个方向战略性问题，我在论支付宝与12306的业务类型可比性是从NoSQL的第一批人，对于HFT低延迟为王(低延迟意味快速响应，特别是大访问量情况下快速完成用户交易)，当然，你可以进行高难度篮球投篮，你也能使用关系数据库完成低延迟，但是关系数据库真的不是为这个目标设计的。.
Oracle试图否定上面的结论，他通过购买TimesTen, 试图将基于内存数据库和RDBMS结合, 但是你会捡了芝麻丢了西瓜，我们看到HFT大部分使用key-value存储，泪如Riak，甚至更复杂如Gemfire.
4. 商品分类编目: 使用SQL来映射商品不是一件令人愉快的事情，当我为一家移动电话商家服务，商品是手机，除了标准模型以外还有几种不同性质的手机，在不同市场下都不同的名称，同样的模型可以有完全不同的部件。管理这些扁平化数据很方便的工具我比较喜欢图库类如：Neo4j.
在一个化工企业我还有类似的经验，我们对产品进行了非常吃力愚蠢的字符串映射，但是将产品信息保存在图库中就非常简单方便，即使使用文本数据库如CouchBase 2.0 or MongoDB也还可以。
5. 用户/用户组和权限ACL: 在某个程度上讲， LDAP是最原始的事务，低延迟才是第一追求。
7. 媒体库: 使用关系数据库存储元数据也许还可以(其实最好还是使用文本数据库Couchbase 2.0 or MongoDB), 但是BLOBs类型数据已经维持痛苦经历很长时间，你最好使用分布式存储或集群式的文件系统来保存图片和其他二进制数据，很不幸，很多CMS内容管理系统工程师还是将它们保存到RDBMS.
8. Email: 电子邮件是带有元数据的现代非结构化数据，我们尽可能优化 RDBMS，使用 BLOBs字段做很疯狂的事情， email是关于元数据 搜索 内容，这其中没有任何关系代数，也不需要事务，文件系统就很好，而元数据可以保存在文本数据库。
9. 分类广告: 一个高伸缩 大批用户展示，短小内容，使用文本数据库MongoDB. 最终一致性足够了。
10. 时间系列time-series 有关预测等(大数据分析): 这是最普遍的10个，但它有多种形式，从商品到金融工程师和太阳黑子的天气。有关时间方面的应用对于关系数据库只是一个传说。如果时间是你主要关心的业务核心，那么使用MapReduce-friendly列族比如Cassandra 也许是一个好的解决方案，Datastax 已经针对Cassandra 发布了其时间系列的数据。