数据库设计的一个难题的解决

 

数据库设计难题的求教 

最近在设计一个数据库，但是碰到这样一个难题，一直找不到合适的解决方案，希望有过类似经验的高手能够帮忙分析下，看有没有好的处理策略。

举个管道建设中的例子吧，同样有三个对象：
管道：起点连接对象，结束点连接对象，管道的其他属性信息
管件：管件名称、管件类型
设备：设备名称、设备编号、设备所属单位

关系是：管道的起点和终点连接管件或者设备，而设备和管件没有多少属性是相同的，所以不能合并，这时候表的关系应该如何建？

目前的一种考虑是使用软关联，就是在管道的表里用4个字段，分别是起点对象类型和起点对象ID，终点连接类型和终点连接ID，但是数据库建模时这种关系无法用实体关系图合理的展示，也无法在数据库中用外键关系来描述，无法保证数据的完整性，所以感觉不是很好的解决方案，想知道大家有没有更好的思路。:)

提问者：Enjoy Everyday - 初学一级

最佳答案

其实不必追求实体关系图的合理，也未必非要用外键，虽然可以没有约束，但是依然可以由程序来很好的管理这些

不过非要追求这个的话，我以前倒是做过一个，效果也还可以，可以参考一下：

管道表里包括：起点连接管件ID、起点连接设备ID、终点连接管理ID、终点连接设备ID、其他属性信息

前面四个ID都是外键，管件ID和设备ID分别关联到各自的表，四个都设置为可空，这样在程序中或者select时判断一下到底取哪个，但依然存在的问题是必须由程序来保证起点和终点都各自只有一个ID，另一个要为NULL。

另外一个办法，可以避免这个很麻烦的判断，但是其他地方要麻烦一些，还是这些字段，增加一个起点连接类型和终点连接类型，select的时候在inner join中除了ID关联之外，增加对连接类型的条件，另外也可以使用union all来进行查询

2008/11/20 20:44:11 回答者：丁学
提问者对于答案的评价：觉得第二种和第三方案目前来说更可行一些，因为我们这边要用O-R Mapping来操作数据库，所以第二种方案和第三种可以满足这种需求，不过如果连接点对象的类型扩展了，不只是管件和设备时，扩展起来不如第一种方案灵活，不过鱼和熊掌貌似不能兼得啊，在有更好的解决方案前，采用第二种或第三种方案先。谢谢丁老师了，3种方案中的第三种的设计和使用思路让我学到一些更灵活的东西。