如何在数据库中允许和存储子选项答案

【问题标题】：How to allow for and store sub-options in a database如何在数据库中允许和存储子选项
【发布时间】：2012-06-22 20:04:25
【问题描述】：

我正在为聚会场所制作在线预订系统，我的客户希望为其用户提供某些“套餐”。然后这些包将具有“子选项”，我不确定如何存储它们。例如，如果一个包裹是“气球”，我需要能够在其下存储不同的选项，例如“红色气球”、“绿色气球”等，或者披萨 > 大、中小。

当然，我正在使用一个数据库，它目前设置有一个用于包裹的表格和一个用于预订的表格。 bookings 表有一个列，其中包含引用存储在“packages”表中的记录的包 ID 列表。

现在，我认为解决此问题的最佳方法是在包含子选项的约会表中添加另一列，格式为：

packageid:optionid;package2id:option2id

以及 packages 表中具有以下选项的另一列：

1:red,2:blue,3:green //for options with no add'l price
1:large[$20],2:medium[$15],3:small[$10] //for options that change the price

我想这会起作用，但我觉得必须有更好的方法来做到这一点。如果有人有任何想法，或者以前做过这样的事情，我将不胜感激。

【问题讨论】：

为什么没有包表？您可以使用引用 bookings 的外键将其链接到 bookings 表。这将允许您存储任意数量的数据，而不必担心随着包数量的增加而空间不足。

【解决方案1】：

如果您有可变数量的选项，就像您所做的那样，通常会执行以下操作：

创建一个按 ID 链接包和选项的表。因此，您将拥有 packages 和 options 表，然后您将拥有一个 package_options 表，该表将只有（除了它的 id 和您存储的任何创建/修改日期时间之外）package_id 和 option_id。

然后您将连接三个表以按包获取选项。我不是特别喜欢这种方法，但在关系数据库领域我还没有找到更好的方法。

【讨论】：

是的，但这似乎（对我来说）不包括我将如何存储为每个包选择的选项在约会行中。我不乏如何存储每个包的选项的想法，它是如何将这些选项与每个约会相关联，因为最终用户会选择它们。
如果我理解正确，您似乎只需要另一个表来关联选项、套餐和约会。在这种情况下，您将有一个表，其中的行看起来像 appointment_id、package_id 和 option_id。然后，您将连接这四个表，以获取哪个约会要求哪些包，然后是哪些子选项。我希望这很清楚。我觉得我可能误解了你的问题。
好吧，您可以在 end 选项上创建一个引用父级的列，然后如果您发现我的想法，只需使用连接来相互关联。

【解决方案2】：

有几种方法可以解决这个问题。基本上，您的解决方案越灵活，它就越复杂。既然你在这方面寻求帮助，我会给你一个更简单的解决方案。

制作一张这样的表格：

ID, PackageName, OptionName
1,  Balloons, Red Balloons
2,  Balloons, Blue Balloons
3,  Pizza, Plain
4,  Pizza, Pepperoni
5,  Clown, NULL

然后，当您需要从包列表中进行选择时，您可以从 tblPackages GROUP BY PackageName 中选择 PackageName。用户选择包后，可以 SELECT OptionName from tblPackges where PackageName = 1;

通过这种方式，用户永远无法真正选择单个包，他们实际上是在选择选项，但对他们来说，他们看起来像是选择了一个包，然后选择了一个选项。

如果您熟悉这个概念，您会发现您可以制作一个包表，然后制作一个选项表，并将它们连接起来。但老实说，对于一个小型应用程序来说，这样做并没有性能方面的理由。上面的方法比你最终得到大量连接的混杂的 ID 更容易理解。

希望对你有帮助。

【讨论】：

【解决方案3】：

首先列出您要存储的实体以及它们之间的关系。根据您的描述，您有 3 个实体参与存储约会：

有两个关系：

实体是你的主表，它们之间的关系是外键：

请注意，我在此处已仔细提及 selected 包和选项 - 您可能有其他表格表示可用包和选项，以及我在哪里写的“包详细信息”和“选项详细信息”，您可以只存储对它们的外键引用（尽管您可能想要拍摄快照，特别是价格等重要细节，以便您记录详细信息在预订时）。

【讨论】：

【解决方案4】：

你没有说你使用的是什么类型的数据库（除了在解释中提到表）。

因此，如果我们假设您只是想根据最佳实践获得答案，我建议您使用 schema-free (NoSQL) MongoDB 而不是关系数据库。

否则，请忽略我的评论并阅读其他评论。我猜你需要通过 SQL join 相互连接的两个单独的表。

【讨论】：