連接表vs外鍵數組？

我正在建模多對多的關係，大多數情況下只能從一側訪問關係。它更像是一個層次結構，它是自上而下而不是其他方式訪問的。連接表vs外鍵數組？

調查有屬於許多問題有屬於許多答案。

這兩種關係都必須是多對多的，因爲同一個問題可以在不同的調查中重複使用，並且在許多問題中可以重複使用。這是一項要求。

標準M2M實現將使用兩個聯結表surveys_questions和questions_answers。相反，我在考慮使用PostgreSQL的整型數組來存儲Survey中的question_ids和存儲問題中的answer_ids。

我們可以利用ANY運算符來查詢匹配外鍵數組的所有行。

我們如何使用SQL查詢所有調查問題和問題答案？

我們如何匹配外鍵數組返回的行的順序？即。使用question_ids = [1,2,3]將保證以1,2,3的順序返回問題行。

與聯結表相比（假設索引合適，它們可能是什麼），它如何執行性能？

您是否建議這？是否有這樣的M2M建模資源？

更新

有增加對陣列外鍵到PostgreSQL 9.3參照完整性的建議，但它並沒有得到包括：http://blog.2ndquadrant.com/postgresql-9-3-development-array-element-foreign-keys/

2012-12-12 randomguy

你說多對多，但這聽起來像一對多;多對多意味着每次調查都涉及到幾個問題，每個問題都與幾個調查有關，但這聽起來有點奇怪，當然，您說的這句話'很多'通常與一對多（多對多-many通常被稱爲'擁有並且屬於許多'） – SingleNegationElimination

@TokenMacGuy：抱歉讓我感到困惑。問題可以跨問題進行重複使用，也可以跨多個問題進行回答，從而實現多對多關係。我會替換與HABTM的許多關係。 – randomguy

使用聯結表方法。數組方法不夠標準，所以你不得不提出有關它的工作原理的問題，而另一個是完全標準的。

2012-12-12 13:09:18

聯結表可能會比數組慢得多。請參閱https://gist.github.com/joevandyk/031cf5812bd656887623 –

是的，有時候陣列方法會有性能提升。當然，它是否能夠適應所有情況存在很大的問題，而其中一個主要問題是添加/刪除新鏈接需要修改潛在的長行（示例中爲優惠券），而不是插入/刪除的單行，並在優惠券表上鎖定。 –

同意！如果您不希望修改每個插入的優惠券表，則可以使用coupons_products_array表（coupon_id，product_ids []）。但是這可能會變得愚蠢。 –

回答