我正在设计一个Web应用程序。该应用程序的逻辑基本上是一个向导，当您在前面的步骤中做出一些选择时，它会影响在后续步骤中选择项目的可能性。
USECASE：
第1步 - 用户选择使用item1和item2
步骤2 - 用户可以选择使用item3或item4，具体取决于步骤1中的选项
第3步 - 用户可以选择使用item5或item6或item7或item8，具体取决于step1和step2中的选项
所有描述项目代表具有多个属性的不同产品。不同商品的总数可能达到数百件，每件商品可以在多个其他商品上可靠。
我想获得有关数据库架构的建议。
目标：在数据库中描述itemX如何需要itemY（可能还有itemZ，itemN，...）
我想知道如何在数据库中实现这些依赖项，因为在应用程序代码中有数千行'switch'和'if'是不正确的。
感谢。
答案 0 :(得分：1)
有一件事是肯定的。您需要将关联存储在单独的Join表中。让我们称之为product_dependency_tb。在正常情况下，（如说问卷管理）所有依赖关系都是相同的类型，因此对于每个条目，将有一个依赖项列表。但是，由于您还需要为表名存储其他元数据，因此我认为这是一个不错的解决方案。
Join（assoc）表的结构：
product_id --- Enabled_product_Table --- Enabled_Product_Id
Itemx Table1 ItemY
. Table2 ItemZ
现在，当您查询依赖记录时，您当然需要在应用程序层中使用一些额外的逻辑（或者您可以将其作为一个过程编写）..（更准确地说，您需要在迭代模式下运行select查询以获取所有依赖产品。）
如果您担心性能，那么您还可以将特定表的enabled_product_ids组合在一起。 （作为逗号分隔的字符串，以便您可以执行条件）...
答案 1 :(得分：0)
在各方面，你的问题应该被称为我如何分析/解决问题！ 你在UI和其他设计中思考的那一刻，混合关于item / itemType的讨论！随机的想法[糟糕的头脑风暴]会增加解决问题的时间。
一次想到一件事，那么随着时间的推移，你将更有能力根据焦点和经验处理不同的输入！
首先：基于什么，你假设每个itemType需要表/类？由于实体名为itemType，因此所有项目必须属于itemType的STRUCTURE，因此至少通过[itemTypeId]更正！
第二：你必须选择哪些更容易让你理解/分解问题[数据库设计或用户界面]，但乍一看不是两者。通常情况下，首先使用数据库设计很容易，如果它的众所周知的问题，那么只关注ui启动原型ui会很好，
所以请编辑问题并多想想要获得更多！
祝你好运！ 修改
问题编辑后，我明白问题属于[工作流程设计]。使用工作流程，您可以动态或静态。动态需要在连接节点和实现它们方面有扎实的知识，另一方面“静态”的一个很容易实现，但需要深入分析问题才能分解每个细节，你的大脑可以想到！
对于动态工作流，我强烈建议研究ms-sharepoint实现，因为它完全涵盖了它，并且可以查看其数据库设计。 [我记得他们在sharepoint service 3.0中有一个巨大的表，其中包含超过100列，其工作方式类似于我认为或可能用于审计的基表！]换句话说，您将需要在应用程序中向表添加/删除列在运行时并将它们链接到应用程序逻辑/工作流程过程。这是动态方法的主要困难来源。在大规模上，只有少数软件包'ERPs'，如SAP，SAGE，MS-Dynamics，Oracle Siebel crm设法解决这个问题。
希望这是有帮助的，如果需要我可以添加更多！