MySQL数据库体系结构-多种类型的相互依赖项

有一件事情是肯定的。您需要将关联存储在单独的Join表中。我们称其为product_dependency_tb。在正常情况下（例如问卷调查管理），所有依赖项都是同一类型，因此对于每个条目，都会有一系列依赖项。但是由于您还需要为表名存储其他元数据，因此我认为这是一个不错的解决方案。 Join（关联）表的结构：

 product_id --- Enabled_product_Table --- Enabled_Product_Id

 Itemx          Table1                 ItemY
  .             Table2                 ItemZ

现在，当您查询相关记录时，您当然需要在应用程序层中有一些其他逻辑（或者您可以将其编写为过程）。（更确切地说，您需要以迭代方式运行select查询以获取所有相关记录产品）。 如果您担心性能，则还可以将特定表的enabled_product_ids组合在一起。 （作为逗号分隔的字符串，以便您可以执行in条件）...     

在所有方面，您的问题应称为我如何分析/解决问题！ 稍后，您将在UI和其他设计中进行思考，并混合讨论item / itemType！随意的想法[头脑风暴]将增加解决问题的时间。 一次想到一件事，那么根据重点和经验，您将更有能力处理各种输入！ 第一：基于什么，您假设每个itemType需要表/类？由于实体称为itemType，因此所有项目都必须属于itemType的结构，因此至少由[itemTypeId]正确！ 其次：您必须选择一种更容易理解/分解问题的方法[DB设计或UI]，但乍一看并非两者兼而有之。通常，如果数据库设计有一个众所周知的问题，那么首先进行数据库设计就很容易，否则最好只专注于ui来启动ui原型， 因此，请编辑问题并考虑更多以获取更多！ 祝好运！ 编辑： 经过问题编辑后，我了解到该问题属于[工作流程设计]。使用工作流程，您可以动态或静态化。动态需要连接节点并实现它们的扎实而深入的知识，另一方面，“静态”易于实现，但需要深入分析问题以分解每个小细节，您的大脑可以想到！ 对于动态工作流，强烈建议研究ms-sharepoint的实现，因为它涵盖了全部内容，并且可以查看其数据库设计。 [我记得他们在sharepoint Service 3.0中有一个巨大的表，其中包含100多个列，它们的工作方式与我认为的基本表相同，或者可能用于审核！]换句话说，在应用程序运行时，您将需要向表中添加/删除列在运行时，并将它们链接到应用程序逻辑/工作流过程。这是动态方法的主要困难来源。在大规模情况下，只有很少的软件包“ ERP”（如SAP，SAGE，MS-Dynamics）能够成功处理Oracle Siebel crm。 希望对您有所帮助，我可以根据需要添加更多内容！