如果要儘可能避免多表連線查詢，那在設計資料庫時，有關聯關係的地方，一般從表中除了有引用主表主鍵的外來鍵欄位外，還要有一個或多個欄位存放主表中的關鍵資訊，比如病人表中有所屬醫院所屬科室主鍵的外來鍵欄位，但還可能會有所屬醫院名稱所屬科室名稱的欄位。因為嫌資料冗餘、維護不易，之前自己一般不設計除外來鍵外存放主表資訊的其它欄位，但這樣查詢時又會多添好些麻煩。可如果加上這些欄位，不單單資料冗餘、維護麻煩，也不好保證資料的準確協調統一性。比如如果醫院的名稱被修改了，那按常理病人表中的醫院名稱也得做相應的修改才可以，這樣，如果醫院表被許多表引用，那就得對所有的表執行修改動作，很是麻煩，實現起來也不現實。如果都加上引用約束，依賴資料庫自己的關聯自動更新，覺得也不是很好，影響程式執行速度且不易維護。可如果是在會診單表（類似於訂單表的功能）中出現類似的情況，就無須有這種顧慮，如果這個會診單在產生時醫院是這個名稱，後面名稱有了更改，那會診單中的醫院名稱還是顯示早前的即可，無須做相應更改，這也是符合邏輯的。
類似情況經常出現在字典相關資訊的存取中，平時只在表中存字典編碼，但查詢時又往往要求同時提供字典文字，核心業務表中的字典欄位往往比較多，暫時沒有好的方法一次高效提取完整資訊。後面在做類似設計時，核心業務表，字典欄位比較多的，根據實際情況，考慮同時存入字典編碼和字典文字，這樣可避免部分連線查詢。但同時，還是會出現上面提到的問題，一方面是資料冗餘，一方面業務表中的字典文字有可能會和字典表中的文字不一致——如果字典資訊有更改的話。
這裡很難找到一種兩全其美的辦法，既能避免資料冗餘，又能讓程式在執行讀和寫動作時都方便高效，如何在各方面之間拿捏均衡是個人經驗問題。通常情況下，是在資料的協調性、準確性允許，跨表查詢又不容易（從表外來鍵較多）的業務模組，採用在從表中附加額外欄位的處理方式；在對資料顯示的同步性、準確性有嚴格要求，跨表查詢也相對容易（從表外來鍵較少）的業務模組，採用從表中不設外來鍵以外的附加欄位、而使用關聯查詢的方式獲取完整資料資訊。
在普通的業務系統之外，還有一種情況，可能不得不大量使用函式、子查詢、巢狀查詢。和視覺化部門合作過的一些專案，系統前端引入ECharts，大量的環形圖、柱狀圖、折線圖等用於展現資料統計分析結果。有些圖形需要的資料很難用簡單的SQL一次提取出來，可如果多次提取後再由程式組裝處理，又太過麻煩，最後還得考驗SQL，此種情況是允許子查詢、巢狀查詢、多表連線等複雜SQL出現的。
過去曾藉助外部框架設計出一套異常靈活的架構，封裝了查詢物件，消除掉了SQL語句，應付通用的業務系統足夠，但在做類似這種統計分析功能時卻變得各種不自在，到後來還是覺得直接寫SQL更方便。此處只能在設計的架構上放開一個口，讓開發人員可以自由編寫SQL語句提取資料，最終的查詢結果統一封裝成一個List<Map<String, Object>>，然後交由程式自動序列化成JSON格式（包含多個物件的陣列）返回給前端。
如果要儘可能避免多表連線查詢，那在設計資料庫時，有關聯關係的地方，一般從表中除了有引用主表主鍵的外來鍵欄位外，還要有一個或多個欄位存放主表中的關鍵資訊，比如病人表中有所屬醫院所屬科室主鍵的外來鍵欄位，但還可能會有所屬醫院名稱所屬科室名稱的欄位。因為嫌資料冗餘、維護不易，之前自己一般不設計除外來鍵外存放主表資訊的其它欄位，但這樣查詢時又會多添好些麻煩。可如果加上這些欄位，不單單資料冗餘、維護麻煩，也不好保證資料的準確協調統一性。比如如果醫院的名稱被修改了，那按常理病人表中的醫院名稱也得做相應的修改才可以，這樣，如果醫院表被許多表引用，那就得對所有的表執行修改動作，很是麻煩，實現起來也不現實。如果都加上引用約束，依賴資料庫自己的關聯自動更新，覺得也不是很好，影響程式執行速度且不易維護。可如果是在會診單表（類似於訂單表的功能）中出現類似的情況，就無須有這種顧慮，如果這個會診單在產生時醫院是這個名稱，後面名稱有了更改，那會診單中的醫院名稱還是顯示早前的即可，無須做相應更改，這也是符合邏輯的。
類似情況經常出現在字典相關資訊的存取中，平時只在表中存字典編碼，但查詢時又往往要求同時提供字典文字，核心業務表中的字典欄位往往比較多，暫時沒有好的方法一次高效提取完整資訊。後面在做類似設計時，核心業務表，字典欄位比較多的，根據實際情況，考慮同時存入字典編碼和字典文字，這樣可避免部分連線查詢。但同時，還是會出現上面提到的問題，一方面是資料冗餘，一方面業務表中的字典文字有可能會和字典表中的文字不一致——如果字典資訊有更改的話。
這裡很難找到一種兩全其美的辦法，既能避免資料冗餘，又能讓程式在執行讀和寫動作時都方便高效，如何在各方面之間拿捏均衡是個人經驗問題。通常情況下，是在資料的協調性、準確性允許，跨表查詢又不容易（從表外來鍵較多）的業務模組，採用在從表中附加額外欄位的處理方式；在對資料顯示的同步性、準確性有嚴格要求，跨表查詢也相對容易（從表外來鍵較少）的業務模組，採用從表中不設外來鍵以外的附加欄位、而使用關聯查詢的方式獲取完整資料資訊。
在普通的業務系統之外，還有一種情況，可能不得不大量使用函式、子查詢、巢狀查詢。和視覺化部門合作過的一些專案，系統前端引入ECharts，大量的環形圖、柱狀圖、折線圖等用於展現資料統計分析結果。有些圖形需要的資料很難用簡單的SQL一次提取出來，可如果多次提取後再由程式組裝處理，又太過麻煩，最後還得考驗SQL，此種情況是允許子查詢、巢狀查詢、多表連線等複雜SQL出現的。
過去曾藉助外部框架設計出一套異常靈活的架構，封裝了查詢物件，消除掉了SQL語句，應付通用的業務系統足夠，但在做類似這種統計分析功能時卻變得各種不自在，到後來還是覺得直接寫SQL更方便。此處只能在設計的架構上放開一個口，讓開發人員可以自由編寫SQL語句提取資料，最終的查詢結果統一封裝成一個List<Map<String, Object>>，然後交由程式自動序列化成JSON格式（包含多個物件的陣列）返回給前端。