从职责归属看数据库中关系设计

今天和领导讨论组织结构中的职责归属的时候，讨论到TMT（技术委员会）和CTT（公共技术小组）中（TMT是CTT的上层组织），如果有大的攻关技术任务，是将职责归属到CTT好呢，还是将职责归属到TMT好。

我以为CTT负责好，第一是因为我在CTT；第二我认为TMT是做决策的，具体的事情就该CTT来做。但是领导认为应该属于TMT。原因是这样的，组织中职责是分解的，如果归属到TMT，TMT就会负责CTT具体做的事，否则，由于TMT中没有明显参与，导致TMT最后不清楚CTT做事的方向，最后干脆不负责任。

简单点说，职责归属放到TMT，是因为需要从上而下的职责链关系的存在！

我想到这和数据结构中的单向链表的结构非常相似。更准确的数据结构应该是链式单向树。根记住叶子的指针，这样根就会对叶子的生命周期负责。

更想起数据库中关系的设计，原以为和链表的关系类似，后来却发现还有很大的不同的地方。我们知道，数据库中表和表的关系包含：一对多、多对多、一对一。一对多中的关系指针，其实是记录在子表中的。一对一的关系中，也是一样。记录关系的表，一般都是附属信息表。

为什么数据库中的关系设计会和组织结构中的设计存在这些差异呢？其实这个时候，我们如果再引入数据的内存结构，就会发现，内存的关系归属和组织结构是一样的。于是我们可以先使用内存结构和数据库关系来分析一些原因，以帮助我们更深入地理解：

1. 内存结构是为了运行；数据库关系是为了保存持久化。
2. 内存结构强调快捷直接；数据库关系强调独立持久
3. 内存结构有容量限制；数据库关系可以无限扩大

这些可能是我们以往容易忽视的地方。但是细究下去，却会发现，原来持久化设计和运行机制设计是完全不一样的设计原则。这里面最重要的就是，内存结构强调关联，而数据库强调分离。因为持久化设计中，儿子只要知道父亲就可以了，父亲不需要知道自己有几个儿子。而在内存结构设计中，则倾向于父亲应该知道自己有多少儿子，但儿子是否知道父亲，可以忽略！

关键是什么？效率！内存结构强调效率，如果从儿子找父亲，比较麻烦。殊不知多少儿子找爸爸的悲惨故事发生。而父亲如果知道儿子，那么一般都是生活在一起，父亲找儿子就简单多了。

好了，一个简单的问题，我在这里��嗦了半天。权当为设计爱好者提供一些讨论的论资吧。