我們有一個C++應用程序，它利用一些基本API將原始查詢發送到MS SQL Server。通過我們程序中的各種翻譯單元，我們有簡單的1-2行查詢作爲C++字符串，現在您會看到更復雜的查詢，可能超過20行。在哪裏存儲C++應用程序的SQL代碼？
我不禁想到，更大的查詢，特別是20 +行的，不應該作爲常量字符串嵌入C++代碼中。我想建議將這些拉出到C++應用程序按需加載的單獨文本文件中，但我不確定這是否是最佳方法。
這種情況下典型的設計選擇是什麼？我肯定覺得需要改進，我只是不知道將SQL查詢移出到數據文件（文本文件）是否是最好的想法。
你可以做一個DAL（數據訪問層）。
這將是該程序的其餘部分談判的API。然後你可以在任何東西和任何東西（存儲過程，高速緩存等）上亂七八糟，而不會干擾主程序。
將它們移動到它們自己的文件中，甚至移動到它們自己的存儲過程中。嵌入在應用程序中的查詢無需重新編譯就無法更改，並且根據您的發佈過程，這可能會嚴重損害您對緊急情況做出響應或部署熱修復的能力。你可以改變你的應用程序來緩存文件內容，如果你沿着這條路走，甚至定期檢查文件的更新。
最好的「設計選擇」 - 出於許多不同的原因 - 就是在任何時候/儘可能使用MSSQL存儲過程。我已經看到了將SQL查詢分隔成一個通用模塊的代碼，但我認爲將SQL查詢拼寫爲字符串的方式對於常見的「查詢模塊」（或獨立的文本文件）沒有多大好處文字在模塊中調用它們。
另一方面，存儲過程增加了模塊性，增強了安全性，並且可以大大提高性能。
恕我直言......
我會將SQL嵌入到使用它的C++函數中：它將更易於閱讀和理解代碼的功能。
如果你的SQL查詢分散在你的代碼中，我會說你正在使用的類的整體結構存在一些問題：你應該有一些（或者甚至只是一個）'低級'類來處理與數據庫的交互以及代碼的其餘部分使用這些類。
我個人不喜歡使用存儲過程：如果您必須支持不同的數據庫服務器，那麼移植將是一件痛苦的事情，我從來沒有看到過那麼多的性能改進，並且瞭解您要跳轉的代碼在存儲過程和C++之間來回切換。
您需要考慮這些查詢可能隨時間而改變，並將其與相關C++代碼可能更改的方式進行比較。如果查詢相對獨立於代碼，並且具有更高的更改可能性，那麼我會在運行時從單獨的文件加載它們，或者使用存儲過程。該方法允許在不重新編譯C++代碼的情況下更改查詢。另一方面，如果查詢與C++代碼高度耦合，對其中一個可能伴隨另一個變化的更改，我會將查詢保留在代碼中。這種方法使更改更加本地化，而且不易出錯。
這要看，這裏有一些注意事項：
1）如果你所有的SQL代碼駐留在應用程序，那麼你的應用程序包含在邏輯上相當多的自我。這與您在當前應用程序中所做的一樣好。就速度而言，這可能會稍微慢一些，因爲在運行這些查詢時需要分析SQL（還取決於您是否使用了Prepared語句等可以加速它的速度）。
2）第二種方法是將所有SQL邏輯作爲存儲過程放在服務器上。對於即使是小型SQL查詢，無論是否一行，這都是一種非常受歡迎的方法。你只是建立一個DAL層。在性能方面這是非常好的，但是邏輯存在於兩個不同的系統中，即C++應用程序和SQL服務器。您很可能需要構建一個小型實用程序應用程序，該應用程序可以將存儲過程的輸入和輸出轉換爲模板代碼（無論是C++還是其他），以使您的生活更輕鬆。
3）與上述兩者混合的方法。我不會推薦這條路線。
存儲過程？用你自己的方法把你的數據庫當作一個遠程對象來處理？ – MatBailie 2012-04-09 21:18:31
你希望通過將它們分開來獲得什麼？與加載/執行它們的代碼相比，它們是否經常更改？他們可能會被轉換成存儲在數據庫本身中的存儲過程嗎？他們的細節是否與周圍的代碼密切相關，或者這些代碼是否合理地將它們當作相對抽象的黑盒子？ – 2012-04-09 21:18:44