資料庫，多對多的關係一定要使用中間表嗎？

1樓：Li Chun

題主提出的這種方法

如果我用乙個欄位來記錄行不行（比如話題用問題之間）我在乙個話題的乙個欄位中記錄它下面所有問題的ID，問題一也用乙個字段記錄它屬性話題的ID

可能在一些非關係型的資料庫中更為常見，比如一些key-value或者是文件型的（比如mongodb）資料庫，使用這樣的方法，有可能會犧牲資料的一致性來換取資料的可用性，資料一致性的維護需要靠一些其他的機制或者非同步的資料處理來進行。

當然在實際的使用中，有很多的問題需要考慮，比如說如果存在乙個節點對應非常多的其他的節點，那麼字段或者單一的key中可能會存不下等等。採用乙個關係表儲存關係，在資料的量級可以接受的情況下，其實是乙個相對成熟的方案，很多問題通過一般的關聯式資料庫都可以比較好的來解決。

2樓：4cott

我認為，首先要明確你的需求。

如果你要實現多對多關聯，然後將所有字段展現一起，是有必要的。

如果兩表多對多關聯，就會產生笛卡爾積，這時兩表都是大表，那效率就特別低。有可能睡一覺回來都沒跑完。

解決的方法，尤其對於資料倉儲來講，就是按業務主題拆分，拿銀行信用卡專案關係型資料庫舉例，粒度由大到小：客戶-賬戶-卡-交易

從左往右依次的關聯關係都是一對多。sql實現起來層次簡單清晰，各主題下也不冗餘。

然後在不同主題上，再建立冗餘的寬表，一次資料加工，上層可供多個應用。

3樓：李曉婷

一般兩層關係的資料結構可以設計主從表，通過主表主鍵進行關聯：如通過ID關聯主從表Header 和Details 兩部分。超過兩層關係的資料結構建議只建立一張表，主表資料重複冗餘即可。

不建議建立多個關係複雜的中間表，表越多後期資料處理就約麻煩，出錯率越高。

4樓：Magic

我覺得你說的恰是兩種多對多的關係：

一種是父子級關係，比如子級話題與父級話題之間的關係，這種關係只用乙個表維護即可，即（話題表ID+PARENT_ID+話題欄位....）來維護。

一種是關聯性關係，比如贊、感謝、收藏，這種就得靠關係表來維護，當然可以建個通用型別的關係表來容納這些操作，畢竟都是話題的相關動作。

5樓：茁壯成長的特特

不說正規化 , 不說效能 , 就可行性來說 , 是可以做的我們舉例為學生表m <-> 課程表n

學生表表設計

學生ID 學生姓名課程ID列表

課程表表設計

課程ID 課程名稱學生ID列表

學生表中加入課程字段 , 並將課程的ID以 ',1,2,3,4,5,6,'逗號分的形式寫入

課程表中亦加入學生字段 , 並將學生ID以逗號分的形式寫入這樣就可以用表示多對多關係了

現在我們來選取乙個ID=3的學生的所有課程select * from 課程表 where 課程表.ID in (select 課程ID列表 from 學生表 where 學生表.ID=3 )

直接執行會報錯 , 意思就是這個意思 , 你可以先執行括號中的sql語句 , 把課程ID列表取出來 , 然後再用課程表.ID in

PS:測試效果是效能不及使用中間表來連表查以上.

6樓：馬克唄

按題主說的來做，乙個話題的表屬性包括

'話題id' （主鍵）

'話題資料'

'問題id'

'問題內容'

如果你把所有問題id放到乙個欄位裡，那不符合第一正規化。如果你把問題id放到很多欄位裡，那麼不符合第三正規化。

so...符合正規化的一張表是不能直接處理多對多關係的