我目前正在設計一個使用php，javascript和MySQL的web應用程序。我正在考慮數據庫的兩個選項。比賽管理軟件的數據庫設計
擁有所有錦標賽的主表，其中包含存儲基本信息以及比賽ID。然後，我會創建分區，括號，比賽等表格，並在每個表名稱後添加錦標賽ID。然後當訪問比賽時，我會簡單地做一些事情，比如「SELECT * FROM BRACKETS_ [insert tournamentID here]」。
我的其他選擇是隻有通用的括號，分部，匹配等表格，每個記錄通過適當的比賽鏈接到適當的錦標賽（或與括號，括號匹配等）柱。
我對第一種方法的擔憂是，它對我來說有點太過分了，似乎數據庫可能會很快變得混亂。我對第二種方法的關注是表現。這個計劃希望有一個全國性的，如果不是國際性的，我關心的是一張桌子上有這麼多的記錄，而且有很多人可能同時碰到它，這可能會導致問題。
當談到數據庫管理時，我並不是一個完整的newb;不過，這是我第一次完全獨奏，所以任何和所有的幫助表示讚賞。謝謝！
不要爲每個錦標賽創建表格。表格是實體的類型，而不是實體的實例。如果混淆這些概念，可維護性和可擴展性將會非常糟糕。你甚至這樣說自己：
這一計劃將希望有一個國家如果沒有國際影響力，我很擔心在一個表中那麼多的記錄，有這麼多的人可能擊中它在同一時間，它可能會導致問題。
如果您需要爲每個記錄創建一張整個表格，您將如何擴展到該級別？
關於你的第二種方法的表現，你爲什麼擔心？你有具體的指標來支持這些擔憂嗎？關係數據庫往往是非常適合查詢關係數據的。所以保持你的數據關係。不要試圖創造性地破壞你正在使用的數據庫技術的設計。
您已經命名了幾個類型的實體：
這些SOU nd像桌子給我。根據您查詢數據的方式管理您的索引（也就是說，不要過度編制索引，否則您將通過插入/更新/刪除來支付索引）。適當規範化數據，在審計和報告更普遍的地方去規範化，等等。如果您擔心性能問題，那麼請關注查詢執行路徑以瞭解您訪問數據的方式。稍微的調整可以產生很大的差異。
不要過早優化。它沒有任何實際原因增加了複雜性。
還要注意，你可以爲BRACKETS_ [insert tournamentID here]這樣的東西創建編譯視圖，並從中選擇。 – David
感謝您的答覆，包括實際實體與實體類型的理論方法。這種推理可以幫助我將自己的頭圍繞不同的概念。那謝謝啦！ –
首先，找到您需要存儲的實體;比如錦標賽，賽事，團隊，競爭對手，獎品等。這些實體中的每一個都可能是桌子。
標準做法是爲每個人設置一個主鍵。有時候會有一列（或一組列）唯一標識一行，因此您可以將其用作主鍵。但是，通常最好只是有一個名爲ID或類似數字類型的列。 RDBMS爲這些列創建和使用索引會更快更容易。
存儲它所屬的數據：我希望在events表中看到事件的日期和時間，而不是prizes表中。
另一個關鍵點是符合First normal form，因爲這保證了數據的原子性。這很重要，因爲這會在以後節省很多頭痛。通過正確執行此操作，您也將擁有正確數量的表格。
最後但並非最不重要：將相關索引添加到查詢中最常出現的列。這對性能有很大的幫助。不要擔心行數過多的表，現在RDBMS-es處理有數以億計行的表，它們被設計成能夠有效地完成這項工作。
「數億行」 - 確切地說。我聽說很多開發人員聲稱他們正在處理「大量數據」，他們正在談論成千上萬行，也許數萬行。在「大量數據」的規模上，成千上萬行在統計上與零行不可區分。 – David
約定的大多數開發人員開始跳躍着，有100萬行說數據庫由於數據大小而變慢。我曾與表達達到1,5億行或750GB以上，並仍然有良好的服務器響應。任何數據庫的關鍵是獲得設計的權利。如果你在投入生產之前沒有做好準備，你將不會有一段美好的時光。 – Namphibian
感謝您的回答。我希望我能接受多個答案。但是，上面的一個稍微多一點我正在尋找的答案。但你的答案同樣好。同樣感謝您確認我對數據庫性能所做的假設，但不確定，因此是一個問題。 –
只要出現一個項目的新實例就創建新表的想法非常糟糕，對不起。
A（當然不完全）列表。這絕對是一個不好的做法，應該限制在非常有利的情況下 - 你絕對不會這樣做。
你說：
我不是一個完整的福利局當涉及到數據庫管理;然而，這是我已經完成了第一個獨奏...
你還記得另一個項目，其中每當需要一個新的集合克隆表？如果是的話，你是否注意到這種方法存在一些問題？如果沒有，你是否認爲這正是DBA永遠不會因任何原因而做的事情？
我所從事的大多數項目都是爲每個客戶創建全新的數據庫，從而爲我們服務的每個人創建克隆表。我確實發現了一些問題，這就是我來這裏徵求意見的原因。我仍然在學習如何自己做這件事，所以我還沒有看到所有理由做一個或另一個。感謝您的洞察力和幫助。 –
請記住我的第四點：將數據分散在不同的表格中，使報告/彙總的實際情況幾乎不可能。這是立即放棄這個想法的第一個理由。即使這樣的報告不是1.0版本的要求，你也完全否定了稍後創建一個報告的機會。 –
您提到的方案（爲新客戶克隆表）是有道理的，這樣可以完全隔離不同的客戶，並且可以僅備份一個客戶數據集等。請理解，在這種情況下，這些原因都不適用，並且您的設計會產生很多限制。 –
除了損害代碼的質量和可維護性（正如其他人指出的那樣）之外，您是否確實獲得任何性能也是值得懷疑的。
當你執行...
SELECT * FROM BRACKETS_XXX
...的DBMS需要找到他的名字「BRACKETS_XXX」相匹配的表和搜索在DBMS'es數據字典本身就是一幫做的表格。因此，您正在數據字典表中使用搜索替換表格中的搜索。您支付任何方式的搜索價格。
（字典表可能會也可能不是「真正的」表，可能會或可能不會有與真實表相似的性能特徵，但我敢打賭，這些性能特徵不太可能比「正常」表更好，因爲大數行。此外，數據字典的性能是不可能被記錄在案，你真的不應該依賴於未記錄的功能。）
此外，DBMS會突然需要prepare更多的SQL語句（因爲它們現在是不同的陳述，參考單獨的表格），這將提出額外的前置確保性能。
你究竟需要在這些表格中存儲什麼？參加比賽的日期，誰參加了哪些比賽，誰贏了比賽，參加哪支球隊的球員（如果有任何球隊），獎品是什麼以及獎勵等等。一旦你擁有了所有這些，將會更容易想出一個數據庫模式。 –
我仍然認爲，但我的問題比這更一般。我想我在問，是不是有更多的行或更少的行，更少的表或更少的表是更好？還是它有所作爲？明天某個時候，我會發佈一個更詳細的列表，但是每個表中都有些什麼。 –