主/細節如何工作？

Question

我發現了一些教程，但他們仍然給我提問。

讓我們以2個表格爲例，其中一個表示客戶詳細信息，另一個表示訂單詳情。

的customers數據庫中的表有：

• 的自增整數customer_id作爲主鍵
• 客戶名稱的文本字段
• 詳細聯繫方式的文本字段

而且orders表格有：

• 的整數customer_id其爲外鍵引用customers表
• 一些其他的東西，一堆項目號
• 的整數order_value存儲順序的現金價值的這種基準

我需要兩個數據集組件，兩個查詢和一個連接。

到目前爲止，這麼好？或者我錯過了什麼？現在

，教程說，我必須設置的，其coresponds到數據庫網格顯示orders表是對應於customers表和MasterFields數據源，在這種情況下，數據源的的MasterSource，以customer_id。

還有其他嗎？我是否應該例如將對應於customers表的數據源的查詢的Detailfields設置爲customer_id？

我應該使用屬性還是a paramaterized query？

好的，在這一點上，我們遵循經典教程，可以滾動瀏覽customers數據庫網格，並查看orders數據庫網格中顯示的當前客戶的所有訂單。當用戶點擊customers數據庫網格時，我必須關閉（）;然後打開（）; orders查詢刷新其對應的DB網格。

但是，這些教程似乎總是假定一個靜態數據庫，其內容永遠不會改變。

當我問anothter問題，我給我在那裏用命令的例子INSERT INTO orders...，被告知這是一個壞Thing`，我應該：

• OrdersQuery.Append（）;
• OrdersQuery.FieldByName（'customer_id'）：= [some value]';
• OrdersQuery.FieldByName（'item_numbers'）：= [some value]';
• OrdersQuery。FieldByName（'order_value'）：= [some value]';
• OrdersQuery.Post（）;

是正確的嗎？

我問，因爲在我看來，一個命令把數據在和查詢應該只把它出來，但我可以看到一個命令不會通過數據源的查詢有關聯的數據庫網格。

這是一個選擇的問題，或必須使用的查詢？

如果是這樣，看起來我不能在查詢中使用簡單的SQL函數，如SUM，MIN < AVG，MAX，並且必須將它們移動到我的代碼中。

如果我必須使用查詢，如何實現SQL UPDATE和DROP？

最後，我可以有主/細節/細節關係嗎？

比方說，我希望有一個3 DB網格，其中顯示了客戶總數和所有訂單的平均水平。它從orders表中獲取數據（但不能使用SUM和AVG），每次用戶選擇不同的客戶時都會更新這些數據，從而提供Master/Detail/Detail關係。我只是將它設置爲兩個主/從關係？即，在DB網格，數據源，查詢總量和平均訂單僅指orders並沒有提及customers，即使它使用customer_id？

在此先感謝您的幫助和澄清。我希望這個問題將成爲未來其他人的參考（所以，請隨時編輯它）。

Answer 1

TLDR：在SQL世界中，主/細節是一種古老主義。

當一些人說的「主從」他們不會去一路下跌兔子洞。你的問題表明你確實想要。我想分享一些我認爲有幫助的事情，但我不認爲任何人都可以完全回答你的問題。

1. 最小實現主從的，對於任何兩個數據集，對某些人的目的，無非是一個事件處理程序觸發更多的時候在主表的更改當前所選行。然後該行用於過濾詳細表數據集中的行，以便只有與主行的主鍵相匹配的行纔可見。如果你在Delphi的VCL中的大部分類似TTable的對象中進行了適當的配置，那麼你就可以做到這一點，但即使是沒有明確支持主/明細配置的數據集也可以這樣工作，如果你願意寫一些事件處理程序和過濾器數據。

2. 在我以前的僱主之一，一個人發明了一個主控細節控制器組件，以及一個名爲Kamiak的德爾福的ADO組件的一個已知的變體，它具有一些屬性，只有熟悉的人與BDE-TTable時代概念的主細節不會有預期。這是一個非常聰明的工作，它具有以下功能：

   • 您可以創建一個ADO記錄集並將其保存在內存中，當且僅當主要行被存儲到磁盤。
   • 您可以將這些主從關係嵌套到幾乎任意深度，因此您可以擁有主記錄，詳細記錄和細分記錄。批量更新用於更新，以回答您的問題的這一部分。要處理更新，您需要滾動您自己的ORM或Recordset圖層，或者使用預先構建的緩存/記錄集圖層。從ADO到Delphi的各種類ORM組件，甚至涉及客戶端數據集或包含數據泵的公文包模型的選項都有很多。
   • 您可以修改數據並將其發佈到內存中的臨時區域，並立即刷新所有主要和詳細信息行，或放棄它們。這允許一個近乎對象關係的持久性管理級別。

爲滾你自己的ORM方法似乎上面一樣可愛，是不是沒有它的陰暗面。系統中的奇怪錯誤導致我再也不想使用這種方法。我不想誇大事情，但是我可以虛心地暗示有這樣的事情，就像在主細節的兔子洞中過分地走下去一樣？不要去那裏。或者如果你這樣做，意識到你真的在構建一個小型的ORM，並準備好完成這項工作，其中應包括一套非常穩固的單元測試和集成測試。即使如此，請注意，您可能會發現一些非常奇怪的角落案例，並且可能會發現一些非常邪惡的bug潛伏在您漂亮的ORM/MasterDetail事物中。

就刀片而言，這當然取決於你是建造者還是用戶。一個願意在VCL的任何Table類之上構建內容並且從不想用SQL髒手的人會認爲如果你不害怕SQL，那麼你的方法就是錯誤的。不過，我想知道那個人將如何處理自動分配的身份主鍵。我在表中存儲一個人員記錄，並立即需要取回該人員新分配的ID，這是一個整數，我現在要使用該整數主鍵來將我的詳細信息行與主行相關聯，並且因此我的SQL數據庫被很好地構造，並且具有參照完整性約束，並且因爲我提前想到了所有這些，並且不想這樣做，所以將詳細信息行引用到主行的ID integer中作爲外鍵我反覆一遍又一遍，最終從這裏開始構建一個對象 - 關係映射框架。我希望你能看到你的許多問題有很多可能的答案，這些答案可能導致成千上萬種可能的方法，而且沒有一種方法是正確的。我碰巧是ORM的一個不信任者，我認爲在這個瘋狂的火車上安全的地方是在你開始之前。我手工編寫我的SQL，並且手動編寫我的業務對象，並且我沒有使用任何花哨的Master Detail或ORM的東西。然而，你可以選擇按你喜歡的方式去做。

我將在BDE/dBase/flat-file時代中實現爲「主細節」，現在我簡單地實現爲主行的查詢，第二個查詢細節行，以及主行更改，我刷新了詳細行查詢，並且我根本不在TTable對象中使用MasterSource或相關的主/明細屬性。