（SQL）關係設計問題

我正在使用SQL製作樣本預訂應用程序，其中用戶爲事件購買票據，其中每個事件都有一個位置和一個表演者。（SQL）關係設計問題

到目前爲止，我打算製作一個大型活動表，每行都有表演者，位置，票數以及每個單獨事件引用票據表的關鍵字。那些特定於事件的票據表將具有包含event_ID，customer_ID和票證號碼的行。

位置，執行者和客戶詳細信息將是他們自己的表。

唯一的問題是，如果客戶想要查詢自己擁有哪張門票，則必須搜索每個活動門票表中的customer_ID。我唯一能想到的另一件事是每張客戶都有一張只包含他們購買的門票號碼的小桌子，但我希望能有其他方式避免重複。

如何優化此類服務模型以使其所有功能儘可能高效？（具體的[客戶] - > [國有門票]查詢）

感謝

來源

2014-09-13 ginsunuva

答案不是有多個事件特定的表。當你將相同的數據分成多個表時，你的查詢立即變得複雜，維護是一個巨大的痛苦。你使用的是什麼sql平臺？ – paqogomez 2014-09-13 14:50:54

好吧，我想你回答了你自己的問題。每個活動的門票單獨表格似乎並不是要走的路。您需要一張門票表格，其中包含EventId的列以及其他信息。

一般來說，如果您有添加額外實體的數據模型需要添加表格，那麼您沒有一個好的數據模型。在你的情況下，添加一個新事件需要添加一個新的事件票據表。如果性能是一個問題，關係數據庫有很多工具可以提高大型表上的查詢性能。

一些添加表，而不是行的問題：

部分填充數據庫頁可以開始吃了大量的磁盤空間和本地網頁緩存，並有準確的你想要什麼相反的效果。
查看跨事件的數據需要將可變數量的表隨時間變化。
對數據庫的修改需要更改大量的表。
對數據（安全性）的訪問控制必須在所有表上進行復制。

來源

2014-09-13 14:51:52

因此，只有一張門票表沒有問題，即使它將成爲一個擁有超過100,000個條目的巨大表格？ – ginsunuva 2014-09-13 15:03:56

@ user17259。。。 100,000行不是「大」表。 SQL可以支持數百萬甚至數十億行。您可能需要索引來提高性能。 – 2014-09-13 15:05:24

@ user17259，我同意Gordon Linoff的觀點，即無論表大小如何，正確的索引都能提供良好的性能。解決這個問題的一個方法是隻要您僅觸摸查詢所需的那些行，您將獲得與大小無關的相同性能。有用的索引允許你這樣做。我與億行表一起工作，並且由於關注索引和查詢調優細節，查詢是次秒。 – 2014-09-13 15:57:41

（SQL）關係設計問題

回答

相關問題