您可以制作 DAL（数据访问层）。
这将是程序其余部分与之对话的 API。然后你就可以在不干扰主程序的情况下乱来尝试任何事情（存储过程、缓存等）。
这真的取决于，这里有一些注意事项：
1）如果您所有的 sql 代码都驻留在应用程序中，那么您的应用程序在逻辑方面几乎是自包含的。这很好，就像您在当前应用程序中所做的那样。在速度方面，这可能会慢一些，因为当您运行这些查询时需要解析 SQL（也取决于您是否使用了准备好的语句等可以加快速度）。
2）第二种方法是将所有SQL逻辑作为存储过程放在服务器上。对于即使是小型 SQL 查询（无论是否为一行），这都是一种非常受欢迎的方法。您只需构建一个 DAL 层。就性能而言，这非常好，但是逻辑存在于两个不同的系统中，即您的 C++ 应用程序和 SQL 服务器。您很可能需要构建一个小型实用程序应用程序，该应用程序可以将存储过程的输入和输出转换为模板代码（无论是 C++ 还是任何其他代码），以使您的生活更轻松。
3）与上述两者混合的方法。我不会推荐这条路线。
将它们移动到它们自己的文件中，甚至移动到它们自己的存储过程中。嵌入在应用程序中的查询不能在不重新编译的情况下更改，并且取决于您的发布程序，这可能会严重影响您响应紧急情况或部署热修复的能力。如果您走这条路，您可以更改您的应用程序以缓存文件内容，甚至定期检查文件是否有更新。
最好的“设计选择”——出于许多不同的原因——是随时随地使用 MSSQL 存储过程。
我已经看到将 SQL 查询分离到一个公共模块中的代码，但我认为公共“查询模块”（或独立文本文件）与在模块中将 SQL 查询拼写为字符串文字相比没有多大好处那是在召唤他们。
另一方面，存储过程增加了模块化，增强了安全性，并且可以极大地提高性能。
恕我直言...
我会将 SQL 嵌入到使用它的 C++ 函数中：它会更容易阅读和理解代码的作用。
如果您的代码周围散布着 SQL 查询，我会说您正在使用的类的整体结构存在一些问题：您应该有一些（甚至只有一个）“低级”类来处理与数据库，其余代码使用这些类。
我个人不喜欢使用存储过程：如果你必须支持不同的数据库服务器，移植会很痛苦，我从来没有见过这么多的性能改进，并且要理解你必须在之间来回跳转的代码存储过程和 C++。
您需要考虑这些查询可能如何随时间变化，并将其与相关 C++ 代码可能如何变化进行比较。如果查询相对独立于代码，并且更改的可能性更高，那么我会在运行时从单独的文件中加载它们，或者改用存储过程。这种方法允许在不重新编译 C++ 代码的情况下更改查询。另一方面，如果查询与 C++ 代码高度耦合，使一个更改可能伴随另一个更改，我会将查询保留在代码中。这种方法使更改更加本地化并且不易出错。