10种不可以使用关系数据库的场景

在一个化工企业我还有类似的经验，我们对产品进行了非常吃力愚蠢的字符串映射，但是将产品信息保存在图库中就非常简单方便，即使使用文本数据库如CouchBase 2.0 or MongoDB也还可以。

5. 用户/用户组和权限ACL: 在某个程度上讲， LDAP是最原始的NoSQL数据库，LDAP是为用户权限设计的。可惜当技术发展LDAP成为过去时，开发人员只好使用创建数据表的方式来欺骗蒙混过关。在企业软件中，User表和Role表方式不能再这样走下去了。

6. 日志分析: Hadoop 或是和小型集群的 RHQ/JBossON 是一个好的选择，将除了错误以外日志截获到这两个系统中，做一件很复杂的事情，生活将变得更糟糕(苦逼程序员有时可能是自找的)，非结构化数据正是 MapReduce强项，可以使用PIG之类方便操作，但是主流系统监控工具大部分是基于RDBMS，实际上日志分析真的不需要事务，低延迟才是第一追求。

8. Email: 电子邮件是带有元数据的现代非结构化数据，我们尽可能优化 RDBMS，使用 BLOBs字段做很疯狂的事情， email是关于元数据 搜索 内容，这其中没有任何关系代数，也不需要事务，文件系统就很好，而元数据可以保存在文本数据库。

9. 分类广告: 一个高伸缩 大批用户展示，短小内容，使用文本数据库MongoDB. 最终一致性足够了。

10. 时间系列time-series 有关预测等(大数据分析): 这是最普遍的10个，但它有多种形式，从商品到金融工程师和太阳黑子的天气。有关时间方面的应用对于关系数据库只是一个传说。如果时间是你主要关心的业务核心，那么使用MapReduce-friendly列族比如Cassandra 也许是一个好的解决方案，Datastax 已经针对Cassandra 发布了其时间系列的数据。

这个深有体会，在不同市场下都不同的名称，对生产制造结构特征没有影响，纯粹是为了销售需要，模型可以有完全不同的部件，这是部件之间的可选关系，还有就是相同部件不同特征的可选关系，部件之间的依赖可选关系，部件特征的依赖可选关系，这个产品模型会很复杂， SQL来映射是很麻烦，但不是没法实现。。

是啊，我看到你在业务建模：BoundedContext(有界上下文)举例Product中也说明这个问题。模型复杂多变，带来的持久也不方便，一旦改变起来修改维护也不方便。图库Neo4J实际是一个很好的对象化持久方式，至少熨平了一些过去对象和关系数据库阻抗。

如果再进一步延伸，部件之间除了数量特征的约束之外，还需要生产装配顺序、损耗工时，加上生产工艺、工作中心、资源约束，相信就不是Neo4J所能解决的，还是得回归关系数据库

能否详细解释之?

主要是关系的深度，图数据库（Neo4J）只支持一层关系，而关系数据库可支持无限层次，不知道理解的对不对?
Neo4J怎么表达Relationship之间的Releationship？我看Neo4J相关的例子都是一层的扁平化的结构，所以这种数据库应用范围还是很有限的，哪天有空我找个把Product的例子再拓展一下，看Neo4J能不能存储与遍历？

参考这篇文章：
Modeling a multilevel index in neoj4。

startLeaf-[:NEXT*0..]->middle-[:NEXT*0..]->endLeaf
startLeaf、middle、endLeaf都是node
[:NEXT*0..]之间的relationship对吧，我不想要node之间的遍历查询，
而是想看到[:NEXT*0..]之间的遍历导航关系。

一层Relationship1：ALeaf->[:NEXT*0..]->BLeaf (这是node之间)
二层Relationship2：“ALeaf->[:NEXT*0..]->BLeaf ”与“CLeaf->[:NEXT*0..]->DLeaf ”(这是relationship之间)

请问：使用图数据库如何存储和遍历relationship2？

[该贴被clonalman于2012-11-22 01:54修改过]

我是这样想，不知有没有道理：图库实际是一种树形结构，树分枝和叶，是否可以用枝Node来表达一个relation，将relation包装成Node，类似包装成对象一样，它是否是在用另外一种方式来表达关系呢？而如果采取关系数据库Join方式来表达关系，虽然灵活强大，但是丧失了可伸缩性，图库这种方式可伸缩性很强，可以不断线性增加服务器提高处理能力。

是的,Relation退化为Node,这个图数据库与关系数据已经没什么区别了,其实我想要的不是结点之间的关系,而已一个结点于一个数之间的关系或两棵树之间的相互关系.

举个例子,我们的手机,它的配件可能是机身、电池、SD卡、耳机、手机帖膜等，一般来说，机身、电池是必须件，SD卡、耳机、手机帖膜是可选件，如果我机身的ROM只有1G，装完操作系统、常用软件就什么空间，这时候SD卡可能就变成必须件了，当我的手机是16G的，SD卡就是可选件; 用树来表达手机的组成那是相当给力，但是如何表达node的property对整个树结构的影响了？（SD卡由可选件变为必须件，手机的产品BOM已经发生了变化了，这只是一个简单的例子，实际业务就没这么简单）

存储property适合使用Ke-value的NoSQL，或列族如HBase等，不同NoSQL适合不同的数据结构，不能象关系数据库打包天下了。

节点、节点属性与整棵树的关系，两棵树之间的关系，图数据库如何描述存储？

我是这样思考，你看对不对，因为NOSQL多样化，我的思考边界就不限定在一个图库或Key-value思考，而是从数据或者说对象高度去思考。

Property属性是值，其有Key，这个Key和图库的Node的Key是一样的值，比如：

Class Product{
Long Id; //Key
Collection props;
Catalog cat;
}
我们可以把 Long Id; 和 Collection props;保存到Key-value数据库；而把Long Id; Catalog cat;保存到Neo4J图库。