将附加需求纳入遗留数据库设计

Question

我正在为数据库设计而奋斗，这就是我目前所拥有的。

​

​

以下是问题所在。

1. 我需要介绍一种新的用户类型(集团化管理器)，它们将具有公司集团(集团化)的可见性。一个企业集团经理可以有多个公司，一个公司可以属于多个集团化经理。如果可以增加一家独立的公司，然后在以后的某个日期很容易将其作为企业集团的一部分，这将是有利的。 我发现这很难建模，因为到目前为止，我的所有用户(经理、驱动程序、收件人)都存在于用户表中。这是设计上的，因为它们几乎都有相同的数据字段，我需要为我的站点上的所有用户设置一个登录点。如果我将聚合管理器添加到user表中，它们将与我现有的用户类型没有的其他表有关系。
2. 我对由用户、所有者、包、公司、用户组成的依赖循环感到不安。我觉得这是一种糟糕的形式，但我实在想不出有什么办法可以避免这种情况： 经理、司机和接受者都为一家公司工作。该公司有一组相关的包，但我需要有能力将这些包的子集关联到特定的收件人(他们拥有包)和特定的驱动程序或经理(负责交付这些包)。
3. 我对用户中的"receive_emails“字段不满意，因为它只与”收件人“类型的用户相关。

为了增加问题，该设计已经在使用中，数据必须迁移到任何新的设计中。

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

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

Answer 1

这是另一次尝试。我还是觉得

• 您不应该太担心receive_emails字段，正如我在另一个答案中所解释的那样。
• 您不必将用户划分为不同的用户类型。

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

你可以这样做：

• 坚持您的表“用户”，但删除company_id。
• 您不必对“公司”、“包”、“参与”和“状态”进行任何更改。
• 添加一个表将用户链接到公司。让我们暂时把这张桌子叫做“从属关系”。(我不知道这是不是个合适的名字，我的英语不太好。)与所有权一样，这只是一个链接表，因此唯一的字段是user_id和company_id (形成主键)。
• 现在将company_id添加到“所有权”中。(我知道，因为链接到“包”，所以它是隐式的，但dbms不知道这一点。)因此，添加这个字段，现在dbms看到了该字段，您还可以在package_id + company_id上添加一个约束(外键)到"packages“，并在user_id + company_id上添加一个约束到”附加“。

就这样。您的变化不大，但现在用户可以附属于许多公司(到目前为止，集团化经理，但也许有一天您决定允许收件人与多家公司一起工作，或者让司机一次为多家公司工作)。而且，现在在“所有权”中没有出现错误条目的风险，也没有任何关于“所有权”内容和使用的疑问。

如果您想安全地使用您的receive_emails字段，下面是您可能想要的一种方法(正如我所说的，这并不是真正必要的)：有一个带有两个字段的新表email_recipients : user_id和user_type。是的，又是冗余。但是这样做，您可以对user_type有一个限制，它只允许某些类型(到目前为止只允许“收件人”)。同样，您将拥有一个外键，不仅是user_id的外键，而且是user_id和user_type的外键。

Answer 2

扩展用户！

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

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

如果您想要更好地控制该企业集团实体，请创建企业集团表并为经理们创建一个FK，因此您可以在企业集团和公司之间创建一个关系表，或者如果一个公司不能被两个企业集团所拥有，那么从一个公司到另一个企业集团只能拥有一个FK。

Answer 3

我需要介绍一种新的用户类型

在这些类型的场景中，当需要添加一个新类型时，这将导致模式的重组，从而导致设计上的一个缺陷。

实际上，管理和驾驶是用户所扮演的角色，这些角色可能会随着时间的推移而改变。

在现实中：

用户不是管理器(他是一个人)。

管理用户is-a-role-played-by。

想一想，如果公司决定有服务台的用户。

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

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

在receive-email中使用User-Role字段是一种选择。

我需要为我网站上的所有用户提供一个单一的登录点。

可以让用户、公司和角色作为登录页面的选择(这将对您的应用程序设计产生直接影响)。

我对由用户、所有者、包、公司、用户组成的依赖循环感到不安。

从概念上讲，我们将有接收用户、=>所有权、=>包、=>公司、=>驱动程序或经理用户。

顺便说一句，这是一个关系模型。

企业集团。

​

​