具有不同字段集的记录的数据库设计

Question

问题

1） 我正在寻找一种适当的方法来设计Web应用程序，特别是数据库架构，以便我可以拥有一个包含给定服务的所有核心字段的基表，然后根据服务的类型，我将需要一组额外的字段来与服务关联。

我需要以一种能够直接执行搜索并提供合理性能的方式来执行此操作。我可能正在考虑某种类型的全文搜索，但该应用程序最多只有 5 个并发用户。

我的应用程序的最终目标是能够在整个数据库中搜索任何给定的关键字并返回所有相关记录。我最初希望将每种服务类型的设置字段拆分为具有自己的列的单独表，但我认为这样做可能会导致更复杂的搜索查询（许多联接）或要运行的更多查询每次搜索。

对于提出的任何解决方案，您能否具体说明为什么您认为这是一个合适的解决方案？

2） 我的另一个问题（希望下面会变得清楚）是我的设计当前由一个“服务类型”表组成，我将在其中定义每个产品的核心类型，其中每个服务都是给定产品的“实例” 。

我的问题是，如果我同时拥有产品和服务类型表，我感觉我可能最终会做大部分重复的事情。因此，避免这种重复是我在设计中试图实现的另一个主要目标。

更多细节

我目前正在编写一个自定义 Web 应用程序，用于跟踪按每个客户提供的服务，不仅用于发票（计费周期、开始/结束日期、价格），还用于这些服务的文档（关联的用户帐户、IP地址、实物资产等）。

每个服务都基于一个“产品”表，该表定义了基本产品的名称、价格、计费持续时间、描述等...我们可以有多个相同类型的产品（例如，对于给定产品的不同计划）类型）。例如，我们有以下产品：

• 共享虚拟主机计划一
• 共享虚拟主机计划二
• 共享虚拟主机计划三
• 专用服务器计划
• 虚拟独享服务器方案一
• 虚拟专用服务器方案二

现在我遇到的问题是，我们有许多对于任何给定服务都是通用的字段，但我们也有许多字段会根据正在跟踪的服务的“类型”而变化。根据服务的类型，我将显示所有服务的基本表单，以及用于添加/编辑等的适当表单...

例如，我们有以下服务类型，每个产品（如上所示）都与这些核心服务类型之一相关：

• 共享虚拟主机
• 专用托管
• 虚拟专用主机
• 宽带数字用户线路
• ...

我可能的解决方案

当前的解决方案 - 多个表

目前，在我的数据库中，我有：

服务类型

• 服务类型ID INT PK
• 类型 VARCHAR(40)

产品

• 产品ID INT PK
• 名称 VARCHAR(40)
• 描述文本
• 价格小数
• 计费持续时间 INT
• 类型ID INT (FK ServiceTypes.ServiceTypeID)

服务

• 服务 ID INT PK
• ProductID INT（FK：产品.产品ID）
• 名称 VARCHAR(40)
• 描述文本
• 价格小数
• 计费持续时间 INT
• 主动双边投资协定
• 开始日期日期时间
• 结束日期日期时间

这些是任何服务的主表，然后我还有用于扩展属性的附加表：

服务ADSL信息

• ServiceADSLInfoID INT PK
• ServiceID INT（外文：Service.ServiceID）
• FNN VARCHAR(10)
• 用户名 VARCHAR(20)
• 密码 VARCHAR(20)
• LocationID INT（FK：位置.LocationID）
• ModemAssetID INT（外文：Assets.AssetID）

服务虚拟服务器信息

• ServiceVirtualServerInfo INT PK
• ServiceID INT（外文：Service.ServiceID）
• 服务器名称 VARCHAR(20)
• IPAddress INT（外文：IPAddresses.AddressID）
• HostServer INT（外文：Assets.AssetID）
• 用户名 VARCHAR(20)
• 密码 VARCHAR(20)

服务共享托管信息

• ServiceSharedHostingInfoID INT PK
• ServiceID INT（外文：Service.ServiceID）
• 主机名 VARCHAR(50)
• HostServer INT（外文：Assets.AssetID）
• 磁盘空间配额 INT
• 带宽配额 INT

其他解决方案 - 单表

我正在考虑将所有与服务相关的信息存储在一个表中，无论服务类型如何，并且如果该特定服务不需要这些值，则将这些值设置为 NULL。

• 服务 ID INT PK
• ProductID INT（FK：产品.产品ID）
• 名称 VARCHAR(40)
• 描述文本
• 价格小数
• 计费持续时间 INT
• 主动双边投资协定
• 开始日期日期时间
• 结束日期日期时间
• 用户名 VARCHAR(20)
• 密码 VARCHAR(20)
• FNN VARCHAR(10)
• LocationID INT（FK：位置.LocationID）
• AssetID INT（外文：资产.AssetID）
• ...

我觉得这在搜索方面也可能是一个更容易使用的解决方案，因为为了服务任何与服务相关的数据，我可以在单个表上使用全文搜索，而不必担心将记录连接在一起。

我主要担心的是，我最终会得到一个包含 30 多个列的表，这看起来可能会变得非常混乱。另一件事是它并不能解决我的两个问题，因为我仍然需要核心 serviceTypes 表来找出我需要用于任何给定搜索的字段 - 因此仍然与我的产品表有一些重叠。

我想知道与产品表的某种程度的重叠是否无法避免？

实体-属性-值模型

我也考虑过这个设计。总的来说，我觉得这对我来说太过分了，因为我不需要事情那么灵活和动态。根据服务类型，我们将需要一组字段，但我们需要收集的每个核心服务类型的数据我看不到很快会发生变化，因此这可以是静态的。

在我看来，实现这种级别的灵活性所需的应用程序逻辑对于它带来的好处来说过于复杂。

必须根据从数据库等查询的字段类型来确定要显示的 HTML 表单字段的类型......听起来很痛苦。

如果我可以提供更多详细信息，请告诉我！我希望一切都清楚。

谢谢！

Answer 1

我认为这一切都取决于您设想如何向前发展，特别是随着新服务进入系统，所有这些都是有效的方法，但都有优点和缺点。

使用第一种方法，您会得到一个更干净的主表，但是对于每个服务，您必须创建一个单独的表，对于新服务，您将必须继续执行此操作，对于您的应用程序，这可能会增加一些复杂性，因为每个服务都需要自己的一组用于提取数据的查询（不确定您的架构是什么，所以这是在黑暗中刺伤。我个人认为这最终会受到伤害。

非规范化表方法会更容易查询，但是您可能会创建一个包含大量某些类型的不必要数据的怪物表。稍微不同的方法可能是添加通用字段，即 10 个名为 numX 的字段（其中 x 是 1 到 10），其中包含数字，10 个名为 textx 等等，我认为 salesforce 使用此 aporoach 为客户提供自定义字段。

键值字段方法就像你说的最灵活，但是你失去了类型识别之类的东西，所有东西至少需要在数据库中是相同的类型。

这取决于您的应用程序的性质，5 个并发用户的性能不应该成为问题，所以也许应该关心实施的难易程度。通用方法概述（销售人员方法）可能在这里起作用，并且可能为您提供其他服务，并为您提供一点未来证明，但这取决于您设想的改变程度。

如果变化是一致的，则加载具有不同字段的服务等，键/值方法可能是您最好的选择，但在那个阶段您也可以查看一些 nosql 方法，因为它们可能适合这里的要求，但 mysql 会仍在工作，只是开放讨论。

更新

为了配合评论，如果您不打算频繁地更改服务，我会跳过 noSQL，因为它会增加您的开发复杂性，这可能不会给您带来好处。

如前所述，服务类型可能不会改变太多，那么我认为非规范化的通用方法可能适合您。这样，您的应用程序就可以拥有一个服务区域，并且您可以将其他属性视为“自定义字段”并根据需要进行添加。这样你的应用程序就是通用的。一个不幸的副作用是，您必须通过某种逻辑在应用程序中以某种方式管理它，以测试它是否存在，并且您必须提取所有字段，无论它们是否已填充，对于您当前的需求，可能不是一个巨大的权衡。

通用方法的示例（非常非常简单）。

• 通用字段是所有服务共享的主要字段。

这可能会使搜索有点痛苦，因为您可能（取决于机制）必须在搜索中包含所有字段