戰略上的INSERT

Question

假設在MySQL與同桌的兩排在一起我有一個簡單的MySQL表看起來像這樣：

CREATE TABLE `my_table` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , 
`name` VARCHAR(8) NOT NULL 
) ENGINE = MYISAM ; 

我想創建涉及對方兩行。我考慮過兩種方法。

---

第一個策略：在表中添加一個「related_to」字段。

我正在使用AUTO_INCREMENT來計算ID，我需要5個步驟才能做到這一點。

1. INSERT INTO my_table（name）VALUES（'abc'）;
2. 檢索插入ID（我們稱之爲$ first_id）
3. INSERT INTO my_table（name，related_to）VALUES（ '某某'， '$ last_id'）;
4. 檢索插入ID（我們稱之爲$ second_id）
5. UPDATE my_table SET related_to = '$ second_id' WHERE id = '$ first_id';

---

第二個策略：一個單獨的表與兩個ID的鏈接。也可以通過5個步驟來完成。

1. INSERT INTO my_table（name）VALUES（'abc'）;
2. 檢索插入ID（我們稱之爲$ first_id）
3. INSERT INTO my_table（name）VALUES（ 'XYZ'）;
4. 檢索插入ID（我們稱之爲second_id $）
5. INSERT INTO link_table（item1，item2）VALUES（ '$ first_id'， '$ second_id'）;

---

哪種方式最好在效率方面，還是有這樣做，我很想念的一個更有效的方法？

謝謝你的建議。

Answer 1

使用第三列將在處理方面更高效 - 查詢將稍快運行。
使用單獨的關係在內存使用方面會更有效率 - 您的數據庫將佔用稍少的內存。

我會忍不住去的關係表，因爲它導致歸一化的設計，雖然這將是一個有點困難的工作。它將避免您在related_to值不同步時可能遇到的任何問題。例如，A和B是相互關聯的。 A has related_to = B，B has related_to = A。這是重複數據，因此如果您使用第三列，則需要多一點管理才能保持一致。

根據您的數據量，這些設計中的任何一個都不會有任何真正的性能問題（差異將以毫秒爲單位），所以您應該選擇任何一種更舒適的方式。

Answer 2

如果B僅與A（1-1關係）相關，則使用名爲related_to的第三列，其中存儲來自第一查詢的id。

INSERT INTO my_table (name) VALUES ('abc'); 
Retrieve insert ID (let's call it $first_id) 
INSERT INTO my_table (name, related_to) VALUES ('xyz', '$first_id'); 

若B可以與A，C，d，...和A可與B和C與...使用額外的表等（1一對多或多對多關係） ：

INSERT INTO link_table（item1_id，item2_id）VALUES（'$ first_id'，'$ second_id'）;

Answer 3

如果您選擇上述之一或某種不同的方式來處理這個問題，這是一個設計選擇，我認爲在選擇方面有比計算步驟更多的因素。

這種關係是對稱的嗎？ 它是傳遞性的嗎？
它是父母的孩子嗎？
這些條目是否真的足夠類似於屬於同一個表？

通過重命名你已經差不多隱藏大部分什麼怎麼回事「MY_TABLE」，並只顯示編號和名稱字段。我可以告訴你的是，在做出選擇時，你需要考慮更多的事情，而不是計算插入內容。當你稍後查詢並且想要獲取與另一行相關的所有行時，該怎麼辦？有更新/刪除異常嗎？等等。

可能的解決方案包括你建議的兩種。您還可能有一個type場與type表一起，在這些行可分爲幾類之一，在同一類別中的所有行是「相關」

1. related_to field 
2. many-to-many table 
3. type/category field 
4. parent-child hierarchy (there are many potential solutions for this) 

這更多地取決於關係的性質比插入內容涉及哪些步驟。首先，你可能會選擇比你插入更頻繁的方式。另外，取決於這些行是否可能成組，您可能會考慮插入的存儲過程，並呈現這些計數沒有意義。