数据库设计难题的求教
最近在设计一个数据库,但是碰到这样一个难题,一直找不到合适的解决方案,希望有过类似经验的高手能够帮忙分析下,看有没有好的处理策略。
举个管道建设中的例子吧,同样有三个对象:
管道:起点连接对象,结束点连接对象,管道的其他属性信息
管件:管件名称、管件类型
设备:设备名称、设备编号、设备所属单位
关系是:管道的起点和终点连接管件或者设备,而设备和管件没有多少属性是相同的,所以不能合并,这时候表的关系应该如何建?
目前的一种考虑是使用软关联,就是在管道的表里用4个字段,分别是起点对象类型和起点对象ID,终点连接类型和终点连接ID,但是数据库建模时这种关系无法用实体关系图合理的展示,也无法在数据库中用外键关系来描述,无法保证数据的完整性,所以感觉不是很好的解决方案,想知道大家有没有更好的思路。:)
其实不必追求实体关系图的合理,也未必非要用外键,虽然可以没有约束,但是依然可以由程序来很好的管理这些
不过非要追求这个的话,我以前倒是做过一个,效果也还可以,可以参考一下:
管道表里包括:起点连接管件ID、起点连接设备ID、终点连接管理ID、终点连接设备ID、其他属性信息
前面四个ID都是外键,管件ID和设备ID分别关联到各自的表,四个都设置为可空,这样在程序中或者select时判断一下到底取哪个,但依然存在的问题是必须由程序来保证起点和终点都各自只有一个ID,另一个要为NULL。
另外一个办法,可以避免这个很麻烦的判断,但是其他地方要麻烦一些,还是这些字段,增加一个起点连接类型和终点连接类型,select的时候在inner join中除了ID关联之外,增加对连接类型的条件,另外也可以使用union all来进行查询
提问者对于答案的评价:觉得第二种和第三方案目前来说更可行一些,因为我们这边要用O-R Mapping来操作数据库,所以第二种方案和第三种可以满足这种需求,不过如果连接点对象的类型扩展了,不只是管件和设备时,扩展起来不如第一种方案灵活,不过鱼和熊掌貌似不能兼得啊,在有更好的解决方案前,采用第二种或第三种方案先。谢谢丁老师了,3种方案中的第三种的设计和使用思路让我学到一些更灵活的东西。