很多人说这个太简单了， 但两个项目经理都解决不了， 哈哈，不知道吹牛是不是犯罪！！！

Question

和人事管理一样做，能不能达到你的要求？会员ID，会员，父母ID，配偶ID，子女ID，...其它个人属性列如性别，出生等...然后跟据习惯只查三代内的相关人物，同父母即兄弟。

Answer 1

表明一个会员所有关系可以通过四个ID完成：会员ID，父母ID，配偶ID，子女ID

Answer 2

因为关系描述这一项比较特殊，比如A是B的父亲，那么B就是A的儿子。
但是如果A是B的同事，则B肯定是A的同事。所以关系这个地方得多考虑一下。

Answer 3

综上所述，会员ID，性别，配偶ID，子女ID 可以描述亲属关系了。其他的关系都可以用查询获得。同事关系比较特殊，最基本的描述方法应该是给工作单位编号，工作单位相同的就是同事了。会员ID，性别，配偶ID，子女ID ，工作单位ID 这样基本上可以描述你说的上述关系了
会员ID，性别，配偶ID，子女ID ，工作单位ID

Answer 4

基本信息表
会员ID，性别，工作单位ID婚姻关系表
家庭ID 丈夫ID 妻子ID子女关系表
家庭ID 子女ID

Answer 5

frankhuai(frankhuai)
我这里家庭ID对应的是夫妻
所以如果又是爸爸又是儿子，就是有两条记录家庭ID 丈夫ID 妻子ID
1      张三   张三妻子
2      张三的爸爸  张三的妈妈子女关系表
家庭ID 子女ID
2      张三
2      张三的姐姐
1      张三的女儿

Answer 6

如果同事关系中要描述上司：会员ID，性别，工作单位ID，级别ID其中单位ID相同就是同事
同事中级别ID高的就是领导

Answer 7

会员表:
会员ID
张三
李四会员关系表:
会员ID,会员ID1,关系
张三,李四,妻子

Answer 8

用关系型数据库处理这种人员关系并不是很的。有一种语言是叫prolog是专门处理这种事情的。可以考虑与它集成。

Answer 9

改：
用关系型数据库处理这种人员关系并不是很好的。有一种语言prolog是专门处理这种事情的。可以考虑与它集成。

Answer 10

偶也试试：：）
1，会员基本表：
  会员ID,单位ID,昏否标志，...
2, 会员家庭父表：
  家庭ID（父ID+母ID）or 父ID,母ID（(分别用会员ID)）
3,会员家庭子表：
   家庭ID,子女ID（(也用会员ID)）
4，单位表：
  单位ID,... 
---------------------------------------------------
其中其中同事和家庭是两种基本关系，二者没有必然联系，平行。
家庭又分为一对多的父子关系。
这些是基本关系表，其它的关系应该可以派生出来（比如爷孙关系等），或属于约束的内容（比如性别，年龄等）。
显然遗传关系是层次结构，要用到递归算法。

Answer 11

liujianjun_(流星尔) 的关系表方案括充性比较强.
   跟据实际情况调整一下,我认为比较好.

Answer 12

那个关系表的数据不好维护的，试想新增加一个成员，你需要补充多少条相关记录？而且这种关系可能是没完没了的，有没有想过？还是建议用prolog，就是因为关系理论不能完成所有问题，才会有人研究出这种语言。它的处理方法很有意思的，比如你录入一些“知识”进去：
如果A是B是父亲，B是C的父亲，那A是C的爷爷。你录入的数据只需要两条：
X是Y的父亲
Y是Z的父亲它会推出结论：
X是Z的爷爷所以其实不需要将所有可能的关系都保存（或输入），只需要将必要的保存就可以了，它会自己根据相关的逻辑推出结论来。不过用prolog的可能不多，不好找人来开发，有时间的话，自己研究一下也蛮好玩的：）

Answer 13

当然我是从完整性的角度来讲，如果系统中只需要“父母”、“子女”等少数的关系，就不需要考虑得那么复杂了，那用关系型数据库可以搞定了。所以我觉得要控制复杂度，不要指望将所有可能的关系都加进来。如果真要搞得很复杂，我自己觉得与prolog集成是最好的方法。

Answer 14

基本表
会员ID，会员，父母ID，配偶ID，子女ID    工作单位
001     abc   002,003  004    005,006    A001
另建一个流星尔的关系表,
存放一些不常用的特殊关系.如干爹干妈表舅等.

Answer 15

不知道楼上这位大虾为什么会推荐prolog，难道就是“蛮好玩的”？prolog是一个逻辑性语言，主要用于推理，但是由于应用不多，学习的人少，和其他语言的接口也少，推荐prolog实在不妥，难道整个管理软件全部用prolog实现？只能是“蛮好玩的”。

Answer 16

呵呵，插队了这么多！
说的是：回复人： icevi(按钮工厂) ( ) 信誉：180  2003-06-02 09:22:00  得分:0 
 
 
  那个关系表的数据不好维护的，试想新增加一个成员，你需要补充多少条相关记录？而且这种关系可能是没完没了的，有没有想过？还是建议用prolog，就是因为关系理论不能完成所有问题，才会有人研究出这种语言。它的处理方法很有意思的，比如你录入一些“知识”进去：
如果A是B是父亲，B是C的父亲，那A是C的爷爷。你录入的数据只需要两条：
X是Y的父亲
Y是Z的父亲它会推出结论：
X是Z的爷爷所以其实不需要将所有可能的关系都保存（或输入），只需要将必要的保存就可以了，它会自己根据相关的逻辑推出结论来。不过用prolog的可能不多，不好找人来开发，有时间的话，自己研究一下也蛮好玩的：）
  
 

Answer 17

我并没有说将整个管理软件用prolog实现啊，不要断章取义好不好？我在这里只是推荐一个思路，我也解释了用prolog不好找人来开发。至于是不是采用我的方法，楼主自己会判断的。做程序思路还是开阔点好，我是觉得什么好玩才会去学的那种人，也许学习对你来说是痛苦的事吧？

Answer 18

处理这种网状层次关系，显然RDBMS不是最好的工具。但因为这是数据库版，所以建议不妨就
限定在用数据库解决的最好方案，这样大家可以火力集中。个人认为楼主这个贴还是很有意思的。若是看破红尘的话，所有的所谓技术都不过是人类的游戏而已。：）
---------------------------------------------------------------------
流星尔的关系表，实际上是通过数据冗余，也就是枚举两两间的可能组合关系，来
达到简化算法的目的。但可以推算一下这种组合量，就知道其可行性了。

Answer 19

刚才没说完，有了基本定义之后，找其他亲戚都可以用存储过程之类的来实现。比如说找某人的孙子。找某人的外孙。找某人的阿姨，找某人的舅舅等。或者找某人所有的长辈，或者所有的晚辈都可以用存储过程来实现。按钮说的也就是这个意思，只不过PROLOG是专门做这个的。它只需要你定义好规则，它会自己匹配数据。不过它的主要实现方法是用枚举和递归，效率不一定比数据库查询高。

Answer 20

不用考虑这么复杂吧，就二张表
第一张：存放各会员的基本资料（如：ID，姓名，性别，出生年月等等）
第二张：描述关系（ID，第一张表的ID 亲属关系的描述）在描述关系表是有：小张的爸爸是中张   一条记录
                  中张的爸爸是大张   二条记录
                  小张的爷爷是大张   三条记录
                  小张的老婆是小王   四条记录
如果你想要查找一个小张，那么根据第一张表的ID找出第二张表中的外键ID列出所有，不是有关小张的所有亲属及关系都显示出来了吗？

Answer 21

我前面已经说了
最经济的存储:会员表:
会员ID
张三
李四会员关系表:
会员ID,会员ID1,关系
张三,李四,妻子
李四,张三,丈夫不保证应用效率高

Answer 22

要在关系型数据库中实现面向对象设计.如果爸爸和妈妈离婚问题是不是会更复杂,SQL语句也比较壮观.

Answer 23

会员表(以ID为主键）：
ID，姓名，性别，生日 ...
1 小明    男   1998/12/01 ...
2 小明爸  男   1970/10/01 ...会员关系表（以（IDA，IDB）为复合主键）：
IDA,IDB,称谓
1   2   爸爸      /*这两条记录不一定要求成对出现*/
2   1   儿子称谓关系表（以称谓为主键）
称谓,男性逆向称谓,女性逆向称谓
爸爸     儿子        女儿以下语句可以实现一级正向关系查询。
Select B.称谓，H.* From 会员 H
    inner Join (Select IDB,称谓 From 会员关系 
                Where IDA = (Select ID From 会员)) R 
    ON H.ID = R.IDB逆向查询复杂一些，需用到称谓关系表及会员.性别字段。
多级或跳级查询，更复杂了，你再仔细考虑了。