MySQL數據庫體系結構 - 多種類型的相互依賴的項目

Question

我正在設計一個Web應用程序。應用程序的邏輯基本上就是一個嚮導，當你在前面的步驟中做出一些選擇時，它會影響在後續步驟中選擇項目的可能性。

USECASE：

步驟1 - 用戶選擇使用ITEM1和ITEM2

步驟2 - 用戶必須使用一個選擇項目3或ITEM4，依賴於選擇的在步驟1中

步驟3 - 用戶可以選擇使用項目5或項目6或項目7或項目8，取決於步驟1中的選項和步驟2

所有描述項目repr不同的產品具有多種屬性。不同物品的總數可能會達到數百個，每個物品可以在多個其他物品上可靠。

我想獲得關於數據庫體系結構的建議。

目的：描述了數據庫itemX如何需要itemY（也可能是itemZ，itemN，...）

我想知道如何能夠依賴那些在數據庫中實現，因爲有千在應用程序代碼中的'switch's'和'if'行是不正確的。

謝謝。

Answer 1

有一點是肯定的。您需要將關聯存儲在單獨的聯接表中。讓我們調用這個product_dependency_tb。在正常情況下，（比如說調查問卷管理），所有的依賴關係都是相同的類型，因此對於每個條目，都會有一個依賴項目列表。但是由於您還需要爲表名稱存儲額外的元數據，因此我認爲這是一個體面的解決方案。

的加入（締合）表的

結構：

product_id --- Enabled_product_Table --- Enabled_Product_Id 

Itemx   Table1     ItemY 
    .    Table2     ItemZ 

現在，當您查詢相關記錄，當然你需要一些額外的邏輯在應用程序層（或者你可以這樣寫的過程）。 （更確切地說，您需要以迭代模式運行select查詢以獲取所有相關產品）。

如果您擔心性能，那麼您還可以將特定表的enabled_product_ids組合在一起。 （作爲一個逗號分隔的字符串，以便您可以執行一個條件）...

Answer 2

所有的尊重，你的問題應該被稱爲我如何分析/解決問題！ 你在UI和其他設計中想到的一刻，並混合關於item/itemType的討論！隨機思考[頭腦風暴]會增加解決問題的時間。

一次只想一件事，那麼隨着時間的推移，您將更有能力根據重點和經驗處理不同的投入！

首先：基於什麼，你認爲每個itemType都需要table/class？因爲稱爲itemType的實體，所以所有項必須屬於itemType的STRUCTURE，因此至少通過[itemTypeId]正確！

第二：你必須選擇哪一個更容易讓你理解/分解問題[數據庫設計或用戶界面]，但不是乍一看。通常如果它的知名問題首先與DB設計一起使用會非常容易，否則將開始以ui爲焦點的原型UI，

所以請編輯問題並多想一想以獲得更多！

祝你好運！

編輯：
問題編輯後，我明白，這個問題屬於[工作流程設計。通過工作流程您可以進行動態或靜態。動態需要紮實和深入的知識來連接節點並實現它們，另一方面，「靜態」一個很容易實現，但需要對問題進行深入分析，以細分每個細節和每個細節，您的大腦可以想到！ 對於動態工作流程，我強烈建議研究ms-sharepoint的實現，因爲它涵蓋了完全可以查看的數據庫設計。 [我記得他們讓我在SharePoint服務3.0中有一個巨大的表，它包含超過100列，它們的工作方式類似於我認爲或可能用於審計的基表！]換句話說，您將需要在應用程序中添加/刪除列並在運行時將其鏈接到應用程序邏輯/工作流程過程。這是動態方法的主要難點來源。大規模只有少數軟件包的ERP，如SAP，SAGE，MS-Dynamics Oracle Siebel crm設法解決這個問題。 希望這是有益的，我可以添加更多，如果需要！