重新設計數據庫成本和建議
我正在使用的 Web 應用程序有一個巨大的數據庫，它真的很亂，沒有外鍵，沒有約束，沒有索引，沒有優化，沒有規範化，什麼都沒有。到目前為止，邏輯一直是：如果您需要一個欄位，請添加它，如果您需要一個表，請盡快創建它。一開始，我無法理解這些錯誤的嚴重性，但不得不一直處理壞數據庫造成的障礙，這讓我決定重新設計整個數據庫。我需要知道的是：
- 我應該從哪裡開始，規範化，添加鍵和索引，或其他任何地方？
- 由於這些更改的成本對我的工作來說將是巨大的（我將不得不從頭開始重新設計整個程式碼以適應它），是否值得？我的意思是，這麼大的東西有什麼優缺點（我說大，因為我是數據庫事務的初級水平）。如果有人可以指導我，那就太棒了
一般來說，當你想要修復一個大泥球架構時，最好關註一個小方面，你可以相對快速地修復它並獲得最大的回報。那東西是什麼將因係統而異。一旦你確定了那個東西，然後實施它並尋找機會修復其他東西。隨著時間的推移，你的大泥球會越來越受到控制。這是假設團隊的其他成員都參與了解決您所處的爛攤子的工作。如果他們不致力於擺脫現狀，那麼您將面臨一場您無法贏得的戰鬥。
添加一些索引似乎是一個快速而輕鬆的勝利，所以這可能是一個很好的起點，但是YMMV。
分手時請記住Warren P在評論中提到的內容：
數年造成的爛攤子很少會少於數年的清理工作。
如果有任何成功的希望，你和團隊的其他成員需要長期致力於這項清理工作。
對OP評論的回應：
從數據庫規範化開始不是更好嗎？我的意思是在開發環境中，為了最終得到一個完全結構化的數據庫？有 6 個表必須分開，以便對未來的請求更具“彈性”。
規範化可能會涉及整個系統的許多查詢/語句。這是一個非常侵入性的更改，需要花費大量時間和精力才能顯示出好處。做一些小的增量步驟會更容易、更快、更穩定地改善你的生活。在考慮規範化之前，我會將所有數據訪問轉移到儲存過程中。這將很快給你帶來實實在在的好處，讓你分散工作，並使標準化步驟更容易。
$$ T $$他整個團隊都準備好了，我們正在談論一個 6 個月 - 9 個月的重組一切的項目，但是大老闆們還沒有決定。
在提倡停止一切並進行重新設計之前，請閱讀 Joel Spolsky 的這篇文章。在接下來的 6 到 9 個月內重組舊系統時阻止對現有系統的更新會使業務難以成功。支持目前產品同時改進相同的程式碼庫是 IMO 最聰明的做法（在我看來）。這樣，程式碼庫改進將只是支持目前產品的共生擴展。
**注意：**我並不是建議您讓一個團隊進行重寫（2.0 版），而另一個團隊正在支持目前系統（1.x 版）。