文檔型數(shù)據(jù)庫如何優(yōu)雅地創(chuàng)建多對多關(guān)系？

這是一個取舍的問題。
在做一個項目的時候你為什么選擇文檔數(shù)據(jù)庫而不是關(guān)系數(shù)據(jù)庫？文檔數(shù)據(jù)庫并不是完美的，比如冗余。但是它也能提供很多關(guān)系數(shù)據(jù)庫提供不了的東西，比如水平擴展，高性能。同樣關(guān)系數(shù)據(jù)庫也不是完美的，提供事務(wù)支持的同時就舍棄了分布式的可能性（CAP理論）。接觸得越多，你會發(fā)現(xiàn)很多這樣的特性，有些無論關(guān)系非關(guān)系數(shù)據(jù)庫都支持，有些就只能在一邊支持（或者說一邊支持得更好）。所以什么對你是最重要的？在你選擇了最重要的特性時，就可能需要在一定程度上放棄其他特性。
拿你的例子來說，JOIN在關(guān)系數(shù)據(jù)庫中是再平常不過的事情，但是你可能沒有完全了解它對性能的損傷有多大。特別是到了分布式環(huán)境下，這意味著每個結(jié)點要與其他所有結(jié)點通訊才能確定最終的結(jié)果集。雖然理論上可以做到，但是對性能的影響可以說讓非關(guān)系數(shù)據(jù)庫的性能優(yōu)勢直接大打折扣（比如如果你的集群中有100個結(jié)點時，每條需要JOIN的數(shù)據(jù)所在的服務(wù)器都要與其他99臺通訊才能確定結(jié)果）。因為大部分人選擇非關(guān)系數(shù)據(jù)庫是希望得到水平擴展和高性能的，如果這些對你更重要，那舍棄JOIN當然就是必然的選擇了。那么如果不要JOIN，就必須要有冗余，所以最終的問題變成，水平擴展和高性能，以及數(shù)據(jù)冗余，到底哪個對你來說更重要？如果我能容忍數(shù)據(jù)冗余，會帶來什么問題？可以想象一下，冗余了課程信息，那么在報名過程中，有多大的可能性對課程本身做修改？常識來講可能性是很小的。所以這里的冗余除了浪費空間外，還有很小的可能性在課程修改時造成需要大量更新，以及更新過程中的數(shù)據(jù)不一致情況。
浪費空間會是個問題嗎？你可能聽說過這樣的說法：存儲空間是服務(wù)器中最廉價的部分。這點不多做解釋了，基本上不會太在乎空間。
大量更新和數(shù)據(jù)不一致會是個問題嗎？會，但是它有多大可能性發(fā)生？那么拿很小可能性發(fā)生的一個問題，交換大部分時間內(nèi)性能大幅度提高，是不是更劃算？
實際應(yīng)用當中，根據(jù)實際情況的來評估哪個更劃算，很大部分時候你會發(fā)現(xiàn)，其實冗余理論上有問題，但實際中根本沒影響，或者可以通過一些手段讓這些問題不能造成影響。那么就可以既享受性能優(yōu)勢，又不影響系統(tǒng)邏輯，這就是最好的情況。
還有一小部分時候你會發(fā)現(xiàn)，冗余確實會造成嚴重的問題，那這就是選擇范式模型的時候了。如果應(yīng)用嚴重依賴范式，那就應(yīng)該選擇在這個系統(tǒng)中選擇關(guān)系數(shù)據(jù)庫。