有个疑惑，大家帮忙理清下思路...

[crack7]

有4张表。

A ID
B ID SID(A表的ID）Sign
C ID MID（B表的ID） SID（A表的ID） Sign（和B表相同值）
D ID MID（B表的ID） SID（A表的ID） Sign（和B表相同值）

假设 A：B=1:1关系，B:C/D =1:N关系（父-父-子的关系）。
也就是说，根据A的一条记录，能够确定C/D表和A有关系的数据。


第一个疑惑，该不该在C/D表中冗余一个 A表的外键字段（SID）？
如果加了，可以直接根据A表的ID立刻查找出 C/D中的数据，不需要通过先查找B表的ID。
但存在的问题：破坏了整个表设计的可理解性，使得各个表之间似乎没有了父子关系。

深入到编程应用中，很可能有的程序员就 DeleteC(string sid,string Sign)//sid表示A表的ID
而有的程序是（先根据B表相关条件（如:Sign）找到B.ID） DeleteC(string mid) //mid 表示B表的ID

于是灾难来了，项目一旦大起来，各个模块之间操作方式不一样，很容易产生混淆。
就上述两种方法 DeleteC而言，各有各的好，但是于项目而言，统一、简单才是最好的。

上面的两种方法，思考了很久，感觉有点混乱了，希望大家能够帮忙理清下思路。

[g4_magicvr]

看你要实现什么样的功能的
典型的tree模型的话 只需要知道自己的子节点和父节点就可以了 其他的可以不断顺延去找
如果你非要很方便地找到一个家族tree的话 可以试试双键环形tree 貌似也有人称它为左右编码

[crack7]

纠正下问题：
假设 A：B=1:N关系，B:C/D =1:N关系（父-父-子的关系）。

[monkeyHere]

我觉得没什么问题～
冗余的目的本身是为了方便， 如果能一次查找到位 当然最好，比如ID和NAME， 有的地方就2个都保存，虽然通过ID就可以查询得到NAME
但是也有感觉复杂的时候

比如select sid from C 可以得到sid
如果C里面没有sid， 那么只能 select B.sid from C join B on c.tid=b.tid
对数据库而已 性能上应该是没什么差异的