你觉得什么地方不合理呀？

 我觉得好像也没有什么出问题得地方，

 就是
 设备表，里用户ID对应的是下线用户的ID，这里不知道你们会不会出现一个设备多个下线用户使用得case，如果出现得话，就不号

 下线用户--装置关系表
 这个表，是描述得下线用户和设备得关系，那么还记得上面设备表里也有个用户id也是记得下线id，这里是不是有问题，是不是上面得用户id应该是创建这个设备得用户得id呀。

 设计需要和你的需求一起进行建模，建模的方法和依据就是我们的数据库设计的里的三个范式。

设备表，里用户ID对应的是下线用户的ID，

 这里有问题了，应该是注册用户id，而不是下线用户ID，

 其他的好像没有什么问题了。

引用 5 楼 inthirties 的回复:
 设备表，里用户ID对应的是下线用户的ID，

  这里有问题了，应该是注册用户id，而不是下线用户ID，

  其他的好像没有什么问题了。

 哦 写错了 是注册用户ID

引用 5 楼 inthirties 的回复:
 设备表，里用户ID对应的是下线用户的ID，

  这里有问题了，应该是注册用户id，而不是下线用户ID，

  其他的好像没有什么问题了。

 哦 写错了 是注册用户ID

都放在一张表不太合适吧
 注册用户有十多个键值 需要填写的
 而下线用户的键值就只有几个需要填写的
 难道在添加下线用户时把其他键值都空着

什么表和什么表是多对多的呀。

 设备表--下线用户关系表
 这个当然是多对多的，


 设备表-注册用户表
 这个是多对一的。 一个注册用户可以创建多个设备，而一个设备只有一个创建者。

修改了一下 在下线用户--装置关系表 多添加了一个键值装置管理状态
 注册用户表
 用户名，密码，地址，电话，等一些基本信息，
 设备表：
 设备序列号，设备名称 ，设备信息,用户ID对应的是下线用户的ID，
 下线用户具有的键值：
 管理员ID，用户名，密码，管理权限（管理员，操作员，查看员），而且在这个表中 又将注册用户的用户名密码又添加了一
 次
 下线用户--装置关系表
 装置ID
 下线用户ID
装置管理状态 创建,管理,查看三种状态

引用 12 楼 ami121 的回复:
 修改了一下 在下线用户--装置关系表 多添加了一个键值装置管理状态
  注册用户表
  用户名，密码，地址，电话，等一些基本信息，
  设备表：
  设备序列号，设备名称 ，设备信息,用户ID对应的是下线用户的ID，
  下线用户具有的键值：
  管理员ID，用户名，密码，管理权限（管理员，操作员，查看员），而且在这个表中 又将注册用户的用户名密码又添加了一
  次
  下线用户--装置关系表
  装置ID
  下线用户ID
 装置管理状态 创建,管理,查看三种状态


  下线用户--装置关系表
  装置ID
  下线用户ID
  如果考虑到你这个应用的话
 加个主键id最好。

 至于状态或者操作历史，都可以根据你们的需求对这个表扩展或者是分子表来做选择，还是根据上面提到的，数据库设计范式就是你的指导，有了模型，然后在考虑冗余和性能的矛盾问题。

引用 14 楼 inthirties 的回复:
 引用 12 楼 ami121 的回复:
  修改了一下 在下线用户--装置关系表 多添加了一个键值装置管理状态
   注册用户表
   用户名，密码，地址，电话，等一些基本信息，
   设备表：
   设备序列号，设备名称 ，设备信息,用户ID对应的是下线用户的ID，
   下线用户具有的键值：
   管理员ID，用户名，密码，管理权限（管理员，操作员，查看员），而且在这个表中 又将注册用户的用户名密码又添加了一
   次
   下线用户--装置关系表
   装置ID
   下线用户ID
  装置管理状态 创建,管理,查看三种状态


   下线用户--装置关系表
   装置ID
   下线用户ID
   如果考虑到你这个应用的话
  加个主键id最好。

  至于状态或者操作历史，都可以根据你们的需求对这个表扩展或者是分子表来做选择，还是根据上面提到的，数据库设计范式就是你的指导，有了模型，然后在考虑冗余和性能的矛盾问题。

 感觉这个需求的主要问题 是用户设置方面的合理性 如何处理好注册用户，下线用户以及他们之间的关系 整个数据库的设计也就不难了