Mysql 将其他需求纳入遗留数据库设计

我正在努力进行数据库设计，这就是我目前所拥有的

问题就在这里

我需要引入一种新的用户类型（聚合管理器），这样他们就可以看到公司集团（聚合）。一个集团经理可以有多个公司，一个公司可以属于多个集团经理。如果可以增加一家独立公司，然后在以后的日子里很容易将其作为集团的一部分，这将是有利的

我发现这很难建模，因为到目前为止，我的所有用户（经理、驱动程序、收件人）都存在于users表中。这是经过设计的，因为它们都有几乎相同的数据字段，我需要为我的站点上的所有用户提供一个单一的登录点。如果向users表中添加聚合管理器，它们将与现有用户类型没有的其他表建立关系

我对通过用户、所有者、包、公司、用户形成的依赖循环感到不安。这给我的印象是糟糕的形式，但我真的想不出一种方法来避免它：

经理、司机和接受者都为一家公司工作。该公司有一组相关的软件包，但我需要能够将这些软件包的子集与特定的收件人（他们拥有软件包）和特定的驱动程序或经理（负责交付这些软件包）相关联

我不喜欢用户中的“接收电子邮件”字段，因为它只与“收件人”类型的用户相关

为了增加问题的严重性，这种设计已经在使用，数据必须迁移到任何新的设计中

系统中最常见的操作是由收件人查看状态，然后由管理员和驱动程序创建状态

我的问题能用优雅的新设计解决吗？

扩展用户

像扩展一个类一样，您可以创建一个新的表“Managers”，其中包含更多列和一个FK给用户

因此，您可以在经理和公司之间创建一个关系表

---

如果您想更好地控制该集团实体，请创建集团表并向经理发送FK，这样您就可以在集团和公司之间创建一个关系表，或者如果一个公司不能由两个集团拥有，则只需发送公司到集团的FK。

3:不要太担心接收电子邮件字段。请记住，您的数据库只是真实世界的一个模型，并不一定要完美。是的，您可以使“收件人”成为自己的表。想想你会得到什么，你会失去什么。事实上，这不是一个糟糕的设计。如果用户不是收件人，您可以使用触发器将接收电子邮件设置为false。或者使用视图隐藏处理驱动程序或经理的应用程序的字段。随你的便。好的，如果你真的想去掉这个字段，你可以有一个“emeil_recipients”表，其中包含所有电子邮件收件人的用户ID。你看有很多方法可以解决这个问题，它们都有各自的优点和缺点。你的设计很好

2：据我所知，每个包最多有一个经理、一个司机和一个收件人。是这样吗？那为什么要有一张桌子“所有权”呢？在“packages”表中输入三个字段；用户id驱动程序、用户id管理器、用户id接收者。所以你的模型更接近现实。（您可以创建一个视图“ownerships”，以在迁移期间替换表“ownerships”。）

1：现在来看看集团。最简单的方法是引入两个新表：首先，您将有一个表“company\u groups”，其中有一个id，可能还有一个description字段。表“users”将有一个字段“company\u group\u id”，它将替换字段“company\u id”。因此，您可以将用户链接到公司组，而不是单个公司。第二个新表是“company\u group\u members”，只有两个字段，id\u company\u group和id\u company。您将构建仅由一家公司（针对经理、接收者和驱动者）组成的“组”，以及由更多公司组成的组（针对集团经理的集团）。因此，您的数据库没有太大变化，但提供了您所需要的一切

尽管如此，您仍然可以考虑将表“用户”减少为公共字段，并将新表“管理者”、“接收者”、“驱动者”和“聚合管理者”包含其他字段。这使您更接近现实，并使到包的链接更清晰。然而，它是以一种与您当前的模式更为不同的模式为代价的。如果以后再加上副驾驶、秘书或其他什么呢？每次都有一张新桌子换一份新工作？再次强调：构建模型的方法有很多。选择一个最适合你的

我希望我的建议能帮助你把事情想清楚

我需要引入一种新的用户类型

在这些类型的场景中，当需要添加新类型时，这将导致架构的重组，导致我在设计中出现缺陷。

实际上，管理和驱动是用户扮演的角色，随着时间的推移可能会发生变化。
实际上：
用户不是管理者（他是个人）。
管理是由用户扮演的角色。
考虑一下公司是否决定使用帮助台用户。

我将添加

角色

和

用户角色

表，以保持用户和角色之间的关系

我对用户中的“接收电子邮件”字段不满意

在

用户角色

中设置

接收电子邮件

字段将是一个选项

我需要有一个单一的登录点为所有用户在我的网站

在登录页面上选择用户、公司和角色可能会有所帮助（这将对您的应用程序设计产生直接影响）

我对通过用户形成的依赖循环感到不安， 所有权、包