最近在设计一个数据库,但是碰到这样一个难题,一直找不到合适的解决方案,希望有过类似经验的高手能够帮忙分析下,看有没有好的处理策略。举个不恰当的例子吧,就说我要在数据库中存储三种类型的对象,我建立三个表:“人”,“猫”,“狗”。三个表的关系是“人”有一个属性,就是字段“宠物”,他可能是一只“猫”,也可能是一只“狗”,而“狗”和“猫”也可能属于不同的人(虽然有点不合理,但是假设他是合理的),然后我就蒙了,不知道这个数据库该怎么建了,大家有好的解决方案吗?

解决方案 »

  1.   

    就是你的表要保存什么内容,三种不同的类型要有一个字段type来区分
    其他字段的属性可以一样
      

  2.   

    刚才思路不是很清楚,所以上面的例子举得有点不恰当,换个例子,举个管道建设中的例子吧,同样有三个对象:
    管道:起点连接对象,结束点连接对象,管道的其他属性信息
    管件:管件名称、管件类型
    设备:设备名称、设备编号、设备所属单位关系是:管道的起点和终点连接管件或者设备,而设备和管件没有多少属性是相同的,所以不能合并,这时候表的关系应该如何建?目前的一种考虑是使用软关联,就是在管道的表里用4个字段,分别是起点对象类型和起点对象ID,终点连接类型和终点连接ID,但是数据库建模时这种关系无法用实体关系图合理的展示,也无法在数据库中用外键关系来描述,无法保证数据的完整性,所以感觉不是很好的解决方案,想知道大家有没有更好的思路。:)
      

  3.   

    如果你一定要使用数据库约束来实现,
    那么你可以建立PIPE_NODE或者说CONNECT_POINT对象,"管件" 和 "设备" 分别引用其作为外键,而"管道"只需要将它的两个端点外键引用到该实体上,
    方便模型扩展,以这个例子本身考虑,如果将来每种设备连接点需要新增加"设备"及"管件"连接特性之类的信息(比如,允许的联接类型=焊接/铆接/法兰连接/螺纹连接,设计压力,管径等),象三通之类的"管件",可能有多个不同的连接点,不同的连接点连接特性可能并不一样.那么上述结构完全可以满足.当然实际决策就和你的业务密切相关了.
      

  4.   

    5楼的回复太绝了,呵呵,我都不知道该怎么说,您这种思路跟我们设计的满足将来扩展性解决方案的数据模型几乎完全一样,不一样的地方是我们在“连接点”的表里面加了一个类型字段和所属对象ID字段,用来做反查,通过二次查询反查连接点所属的设备或者管件,当然这个关系不能用E-R图很好的反映,这是遗憾的地方~,不过只要在程序上做合适的控制,模型还是能很好的工作的~
    5楼老师的恢复给了我们点点信心,谢谢了,结贴去^_^