将其他要求合并到遗留数据库设计中

Question

我正在努力进行数据库设计，这是我到目前为止所做的。

以下是问题。

1. 我需要引入一种新的用户类型（集合经理），他们将了解公司集团（集团）。集团经理可以拥有多家公司，公司可以属于多个集团经理。如果可以添加一个独立的公司，然后在以后很容易将其作为集团的一部分包括在内，这将是有利的。

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

2. 我对通过用户，所有权，包，公司，用户形成的依赖循环感到不安。这让我感觉很糟糕，但我真的想不出一种避免它的方法：

   经理，司机和收件人都为一家公司工作。该公司有一组相关的软件包，但我需要能够将这些软件包的子集关联到特定的收件人（他们自己的软件包）以及特定的驱动程序或管理员（负责提供这些软件包）。

3. 我对用户中的“receive_emails”字段不满意，因为它只与“收件人”类型的用户相关。

要添加问题，此设计已在使用中，并且必须将数据迁移到任何新设计。

系统中最常见的操作是收件人查看状态，然后由经理和司机创建状态。

我的问题可以通过优雅的新设计来解决吗？

Answer 1

扩展用户！

与扩展课程一样，您可以为用户创建一个包含更多列和FK的新表“Managers”。

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

如果您希望更好地控制该集团实体，请创建Conglomerate表并向经理人提供FK，这样您就可以在Conglomerate和Companies之间建立关系表，或者如果一家公司不能由两家企业集团拥有，那么只需要公司的FK聚集。

Answer 2

  

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

在这种情况下，当需要添加新类型时，这会导致架构重组，这会导致设计出现缺陷。

实际上管理和驾驶是用户可能会随时间变化的角色。
实际上：
用户不是经理（他是一个人） 管理用户是角色扮演 想想公司是否决定有服务台用户。

我将添加Role和User-Role表来保持用户和角色之间的关系。

  

我对用户的“receive_emails”字段不满意。

在receive-email中添加User-Role字段是一种选择。

  

我需要为我网站上的所有用户设置一个登录点

可以在登录页面上选择用户，公司和角色（这会对您的应用程序设计产生直接影响）。

  

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

从概念上讲，我们将拥有recipient-user =＆gt; ownership =＆gt; package =＆gt;公司=＆gt;司机或经理用户。
BTW是一个关系模型。

  

团块。

Answer 3

3：不要过于担心receive_emails字段。请记住，您的数据库只是现实世界的模型，并不一定非常完美。是的，你可以让“收件人”成为自己的一张桌子。考虑一下你会获得什么以及你会失去什么。事实上，这不是一个糟糕的设计。如果用户不是收件人，您可以使用触发器将receive_emails设置为false。或者使用视图来隐藏处理驱动程序或管理员的应用程序的字段。就像你喜欢的那样。好吧，如果你真的想摆脱这个领域，你可以有一个表“emeil_recipients”，其中包含所有用户ID，他们都是电子邮件的收件人。你看，有很多方法可以解决这个问题，它们各有利弊。你的设计很好。

2：据我所知，每个包最多只有一个经理，一个司机和一个收件人。是这样吗？那为什么要有一张桌子“所有权”呢？将三个字段放在“包”表中; user_id_driver，user_id_manager，user_id_recipient。所以你的模型更接近现实。 （您可以创建视图“所有权”以在迁移期间替换表“所有权”。）

1：现在到了集团。最简单的方法是引入两个新表：首先，您将拥有一个带有id的表“company_groups”，可能还有一个描述字段。您的表“users”将有一个字段“company_group_id”，它将替换字段“company_id”。因此，您将用户链接到公司组而不是单个公司。您的第二个新表将是“company_group_members”，只有两个字段，id_company_group和id_company。您将构建仅由一个公司（针对经理，收件人和司机）组成的“组”，以及由更多公司组成的组（集团经理的集团）。所以你的数据库不会改变那么多，但提供你所需要的一切。

说了这么多，你仍然可以考虑将你的表“用户”减少到公共字段，并让新表“管理员”，“收件人”，“驱动程序”和“conglomeration_managers”包含其他字段。这使您更接近现实，并使包的链接更清晰。然而，它的代价是与现有型号不同的型号。如果你以后添加联合司机，秘书或其他什么呢？每次换新工作的新表？再说一遍：构建模型的方法有很多种。选择最适合你的那个。

我希望我的建议可以帮助你全面思考。

Answer 4

这是另一种尝试。我仍然认为

• 你不应该过多关注receive_emails字段，正如我在其他答案中所解释的那样。
• 您不必将用户分为用户种类。

你在2中担心的是依赖关系。依赖关系通常不是问题，但您在基于id的数据库设计中非常严格，因此隐藏了dbms的依赖关系。如果它只是知道，它可以帮助你： - ）

你可以这样做：

• 坚持使用“user”表，但删除company_id。
• 您无需对“公司”，“套餐”，“参与”和“状态”进行任何更改。
• 添加表格以将用户链接到公司。我们暂时将表格称为“附属机构”。 （我不知道这是否是一个合适的名字，我的英语在这里让我失望。）像所有权一样，这只是一个链接表，所以唯一的字段是user_id和company_id（形成主键）。
• 现在将company_id添加到“所有权”。 （我知道，由于你链接到“包”，它有点隐含，但dbms不知道。）所以添加字段，现在你的dbms看到了字段，你也可以添加一个约束（外来的）密钥）在package_id上​​加上company_id到“packages”以及对user_id的约束加上company_id到“affilations”。

就是这样。你没有太大改变，但现在一个用户可以加入许多公司（集团经理到目前为止，但也许你决定有一天允许收件人与多家公司合作或让司机为一家以上的公司工作时间）。现在“所有权”中没有错误输入的风险，或者对内容和使用有任何疑问。

如果你想使用你的receive_emails字段安全地玩，这里有一种你可能想要的方式（正如我所说，这不是必需的）：拥有一个包含两个字段的新表email_recipients：user_id和user_type。是的，再次冗余。但是这样做，你可以对user_type有一个约束，只允许某些类型（到目前为止只有“收件人”）。再次，您不仅可以使用user_id，还可以使用user_id加上user_type。