你觉得什么地方不合理呀？我觉得好像也没有什么出问题得地方，就是
设备表，里用户ID对应的是下线用户的ID，这里不知道你们会不会出现一个设备多个下线用户使用得case，如果出现得话，就不号下线用户--装置关系表
这个表，是描述得下线用户和设备得关系，那么还记得上面设备表里也有个用户id也是记得下线id，这里是不是有问题，是不是上面得用户id应该是创建这个设备得用户得id呀。设计需要和你的需求一起进行建模，建模的方法和依据就是我们的数据库设计的里的三个范式。
设备表，里用户ID对应的是下线用户的ID，这里不知道你们会不会出现一个设备多个下线用户使用得case，如果出现得话，就不号下线用户--装置关系表
这个表，是描述得下线用户和设备得关系，那么还记得上面设备表里也有个用户id也是记得下线id，这里是不是有问题，是不是上面得用户id应该是创建这个设备得用户得id呀。设计需要和你的需求一起进行建模，建模的方法和依据就是我们的数据库设计的里的三个范式。
设备表，里用户ID对应的是下线用户的ID，这里有问题了，应该是注册用户id，而不是下线用户ID，其他的好像没有什么问题了。
因为这两个表是多对多的关系在 而且注册用户的信息也写入到了下线用户表中 设备表与下线用户之间在建立一个表
设备表--下线用户关系表
设备ID
下线用户ID
那我这个下线用户--装置关系表
下线用户ID
设备ID 就应该被创建
下线用户--装置关系表
装置ID
下线用户ID
如果考虑到你这个应用的话
加个主键id最好。至于状态或者操作历史，都可以根据你们的需求对这个表扩展或者是分子表来做选择，还是根据上面提到的，数据库设计范式就是你的指导，有了模型，然后在考虑冗余和性能的矛盾问题。
能不能推荐几本好的数据库书籍啊
http://groups.google.com/group/inthirties/files