因此，我最近接管了內部內容管理系統的維護工作，而數據庫優化並不是我的專業領域。與PHP循環的SQL查詢
無論如何，當我查看代碼時，出現了一些情況。
該PHP代碼是一點點「肉丸意大利麪」幾乎沒有評論。但最重要的事情是：據我所知，原始程序員決定完全放棄數據庫代碼中的表連接（隱式和顯式）。
例如這裏是顯示一個頁面欄的過程：
從數據庫 對於每個元素提取元素列表調用子程序來檢查顯示器的權限，如果成功，調用另一個子程序來獲取元素的HTML數據。
每個子例程都有效地爲每個元素調用一個單獨的查詢。我相信權限步驟涉及查詢兩個單獨的表。
表現並不是真正的問題，我並沒有被要求去研究這一點。儘管我認爲頁面請求有點慢。
是否值得嘗試重寫SQL的東西？我認爲可維護性的增加最終是值得的，而且如果可擴展性成爲未來的問題，它會讓我更容易。
或者它不是我認爲的那麼糟糕？也許我只是過度反應。專家意見將不勝感激。
重構是開發過程的重要組成部分。忽視這一事實意味着未來會出現更多問題。問題的一部分是沒有多少管理者理解持續重構的重要性。
我建議您閱讀Joshua Kerievsky的「重構模式」，其中有許多很好的例子，說明如何通過實施新的設計方法安全地更改現有代碼。
至於你關於SQL查詢的問題，它可能是也可能不是你需要改變的第一件事。
我認爲這是值得重寫，而你有時間這樣做。你不想’ t想要推遲它，直到它成爲一個問題。我說，讓數據庫做到最好。在這種情況下，表連接肯定會比循環中的多個查詢執行得更好。
如果想讓您的工作在未來更容易，我會在修復查詢之前重新開始重構意大利麪代碼。一旦你有一個很好的設計，如何整合（甚至可以選擇）一些手動連接也應該更直接。
你的問題有點過於籠統，不能給出一個很好的答案，而且你還沒有提供足夠的信息來爲你的特定情況進行有根據的猜測。
需要注意的事項：
系統會隨着時間而增長嗎？如何？ 如果網上會有更多的用戶，系統上會有更多的安慰 - 那麼就有可能引發報警。設計不好的系統不能很好地擴展。
錯誤的代碼是一回事，但不好的數據庫和一般的系統設計更糟糕。我認爲關鍵可能是你對「未來幾年」的評論。如果你打算長期堅持這個系統 - 那麼認真看待基礎知識是一個好主意。如果你的系統可能被別的東西取代（內部CMS往往被替換），那麼你可以在購買正確的東西的時候打補丁。
但是，正如您的問題所述 - 重寫一些問題，請確保您的數據庫已正常化並重構您的代碼。如果你堅持使用這個系統，告訴你的老闆這是正確的。
我認爲這可能是合理的假設負載會隨着時間的推移而增加。該公司爲小型本地公司做網頁設計。從phpmyadmin的統計數據來看，我認爲如果我們的客戶中的任何一個變得更大，數據庫服務器可能會崩潰。什麼信息會有幫助？我知道這個問題是通用的，可能過於寬泛。會看到主要的數據提取代碼有幫助嗎？ –
你需要把你的問題分解成更小的塊，並在這裏發佈特定的問題。 「如何構建整個程序/系統」的問題太複雜了，無法在這裏處理。就像我說的那樣，你期望系統增長和使用的越多，你就會越早地重建有缺陷的部分。 – Bing
有一個特定的問題或一些代碼？ –
我想知道如果我的僱主沒有要求我嘗試修復完全工作但又醜又慢的代碼是否值得。是否會讓我的工作變得更輕鬆，因爲我有可能成爲未來幾年內唯一必須處理它的人？ –
這是本週第三次，我讀了相同的問題標題（循環中的SQL查詢）。 – feeela