2016-08-14 93 views
1

我有一個像SO這樣的問答網站。我有一個表是這樣的:如何選擇帖子及其所有相關帖子?

// qanda 
+----+----------+----------------------+---------+------+ 
| id | title |  content  | related | type | 
+----+----------+----------------------+---------+------+ 
| 1 | a title | a content   | NULL | 0 | 
| 2 |   | a content   | 1  | 1 | 
| 3 | a title | a content   | NULL | 0 | 
| 4 |   | a content   | 1  | 1 | 
| 5 |   | a content   | 3  | 1 | 
+----+----------+----------------------+---------+------+ 
/* type column:  "0" means it is a question, "1" means it is a answer 
    related column: it contains the id number of its own question 
*/ 

現在我需要選擇一個問題,根據id號自己所有的答案。 (即id號碼可以是問題的ID或答案的編號)

這裏是我當前的查詢:

SELECT * FROM qanda WHERE id = :id OR related = :id 

我的查詢工作以及只有當:id是一個問題的ID。 (我的意思是它不能正常工作,如果:id是答案的編號)


這裏是預期的結果:

assuming either :id = 1 or :id = 2 or :id = 4 
+----+----------+----------------------+---------+------+ 
| id | title |  content  | related | type | 
+----+----------+----------------------+---------+------+ 
| 1 | a title | a content   | NULL | 0 | 
| 2 |   | a content   | 1  | 1 | 
| 4 |   | a content   | 1  | 1 | 
+----+----------+----------------------+---------+------+ 

正如我上面提到的,我需要選擇那些三行如果:id = 1:id = 2:id = 4。我怎樣才能做到這一點?

+0

將您的模式劃分爲問題和答案表格,然後對每個父問題答案都有一個外鍵約束會更有意義。這個當前的設計是一個災難配方 – Alex

+0

@Alex我會改變我的數據庫設計*(爲問題和答案創建兩個分開的表)*就像你在我的網站的下一個版本中說的..目前我需要解決的問題我'米麪臨着。 –

+0

您目前存儲多少數據,如果您現在可以遷移到新的數據庫設計,我會強烈推薦它。當你用這個當前的設計進行縮放時,你會碰到一些嚴重的性能瓶頸, – Alex

回答

1

以下查詢應該可以工作。該查詢分爲4個部分組合在一起。每個查詢的描述:如果:id

  1. 返回問題是一個問題
  2. 返回答案,如果:id是一個問題
  3. 返回的問題,如果:id一個答案
  4. 返回答案,如果:id一個答案

查詢:

select q.* 
    from quanda q 
where q.id = :id 
    and q.type = 0 
UNION ALL 
select a.* 
    from quanda a 
where a.related = :id 
UNION ALL 
select q.* 
    from quanda a 
    join quanda q 
    on q.id = a.related 
where a.id = :id 
    and a.type = 1 
UNION ALL 
select a2.* 
    from quanda a1 
    join quanda a2 
    on a2.related = a1.related 
where a1.id = :id 
    and a1.type = 1 
+0

只有一個問題,爲什麼我的問題已經獲得了兩個downvotes?它出什麼問題了? –

+2

受過教育的猜測:我懷疑有些人因爲他們根本不同意你的數據庫設計而被低估。就我個人而言,我認爲這不是一個合理的理由。 Downvotes應該是(因爲它表示當你將鼠標懸停在downvote圖像上時)顯示缺乏努力的問題,沒有用處或不清楚。雖然不是每個人都可能同意你想要做的事情,但我認爲你清楚地解釋了自己,特別是當我比較SO上提出的90%的SQL問題時。 – sstan

+2

我同意@sstan的評論,儘管我不同意你的數據庫設計,因爲你顯然投入了創建它的時間,所以我實際上贊成了你的文章。這不是低質量的,所以我不相信它值得投票! – Alex

相關問題