活動列表數據模型

我正在製作應用程序，我將顯示活動（體育賽事，音樂會等）。我試圖想出一個模型，我可以選出參加體育賽事的球隊，以及在音樂會上演奏的樂隊/藝術家。活動列表數據模型

我最初的刺痛是它有一個事件表，團隊表，樂隊/藝術家表。但是我無法弄清楚處理兩隊的最佳方式，或者是在比賽中表演的衆多樂隊/藝術家。

如果多個字段不適用於記錄，可以將多個字段設爲NULL嗎？我一直認爲最好限制記錄中NULL字段的數量。

2010-01-05 Seth

「團隊」和「樂隊」或任何其他類型的「事件」所基於的「人物/事物」之間的數據區別是什麼？他們有不同的與他們相關的數據，或者他們只是不同類型的東西？ – 2010-01-11 22:00:28

很多方法來攻擊這個。

你肯定會有一個事件表。

您是否將運動隊和樂隊分爲不同的表格取決於您對每個表格所掌握的信息以及對NULLS的看法。我的理解是，您的記錄中存在空值幾乎沒有性能影響（我確定它會因數據庫而異） - 如果您有大量體育和音樂相關的字段，則真正的缺點是可能是一個笨拙的表格混合在一起。

如果你確實創建了獨立的體育和音樂會表格，你需要考慮如何處理你的問題中的「etc等」。魔術師和刀劍師會走進哪張桌子？

至於連接多個團隊/行爲與事件，我傾向於創建一箇中間表來執行該鏈接。每條記錄都會引用一個事件ID和一個表演者ID。你可以爲一個事件（一個表演者）創建一個記錄，或者爲一個體育賽事（兩個團隊）創建兩個記錄，或者爲多行爲演唱會創建n個記錄。

然後拉起展示賬單，您將查找您的事件，然後使用中間表查找出現在該事件中的所有行爲，並使用這些ID獲取每個行爲的名稱和詳細信息。

來源

2010-01-05 05:48:02 Jay

我想我正在努力尋找最好的方法。希望我能看看一些票務公司如何處理它。他們顯然有正確的數據庫建模。我想我會傾向於有一個更大的桌子，只是處理一些NULL和O如果它的體育，音樂會或劇院測試。 – Seth 2010-01-07 05:28:26

如果門票公司現在正在處理它（並且令人驚訝的是有多少大公司做得不好），請放心，他們過去做得很糟糕，可能很多年，並且通過第二次，第三次和第四次嘗試。您已經領先，但在某些時候，我們只需要接受每個新域名都是學習體驗，並且將會有重構。相應地規劃和預算，並在早期迭代中投入更多精力，因爲早期是最容易重構的時間。 – Jay 2010-01-08 17:36:07

...另外，現在不用擔心數據模式，更多關於在您的域/業務邏輯和該數據庫之間放置API /服務層。只要你完成了正確的操作，就可以在不破壞客戶端代碼的情況下重構數據庫中的內容（例如，在給付支付賬單的人的實際工作之後 - 他們不關心你的模式）。 – Jay 2010-01-08 17:39:12

活動列表數據模型

回答

相關問題