在实际开发过程中业务对数据库的操作是很平常的事情，在简单业务逻辑的时候我们为了图方便，可能直接将业务操作的SQL语句写在代码中。但是这样做会有很多的问题，比如，业务逻辑修改，数据库表修改等都会需要去改动SQL语句，我们把SQL语句写在代码中的话，就必须去修改代码、重新编译发布等等，太麻烦，而且当业务量达到一定级别时也不便于SQL语句的管理。
那么，各位大牛们，从你们的开发经验上来讲，一般是怎样管理和保存业务SQL的呢？
个人不建议把sql语句放到代码中，一般情况应该放到单独的配置文件进行管理，原因有几方面：
1、源代码中如何把sql语句当成字符串处理，对于多行、引号等情况，需要做字符串拼接操作，写起来比较麻烦，看起来也不直观。
2、sql语句分布在各个程序中，如果团队中DBA做sql审核的话，不易提取出sql语句。
3、对于一些局部的修改，如果只是个别sql语句修改的话，理论上可以只替换sql语句所在的配置文件，如果在程序中的话会涉及源程序的编译、部署，处理起来会比较麻烦。
sql代码就和具体业务逻辑一样，是多变的。
改sql代码就基本等于改业务逻辑，当然需要进到具体代码进行修改。
一个项目的sql语句可能有几百条，你如何管理呢？无非把UML图做的详细一些罢了。
我遇到过这样的情况，一般是把最新的SQL表结构导出成SQL语句保存在纯文本的文件中，例如叫backup.sql，用一个初始化函数去读取它执行初始化数据库的工作。
全都保存在一个文本中的局限是，每次对于表结构可能只是增量更新，这样不是很灵活。所以可以根据你们的具体技术栈引入ORM框架，这样就不需要维护SQL，直接维护代码即可。
如果你的代码中就那么几条SQL语句，而且小的业务逻辑修改就是改改SQL，其他都不用改的话，那么把SQL作为配置文件存起来也行。
但是你要是SQL很多，你能保证业务逻辑的修改就是改SQL？如果不能的话，那写在代码里和写在别的地方是一回事了。。
视乎你们怎么管理项目结构而已。
比如我们公司用的是mybatis，很早以前就是用xml+代码的形式去管理SQL，但其实每次更改SQL都是因为业务逻辑发生了改变（这种改变往往不只是SQL改变，代码也要相应修改），所以我们现在都改用注解写SQL的形式了。
所以我个人觉得SQL变动>代码变动的这种情况是相对较少的。
1：我很疑惑，SQL语句不写在代码中，那写在哪里？
2：你担心的问题应该是业务逻辑分离实现的问题，一般业务模型不经常更改，只需要改控制器就可以了，对外部来说，业务模型可以只提供接口，业务逻辑sql操作都被封装在模型中了，“业务逻辑修改，数据库表修改等都会需要去改动SQL语句”这是必然的，正常的。
3：但是如果在往上抽象一层的话，应该是这样的，像大公司，腾讯这样的用户数据库，新同学应该接触不到使用sql去操作的，应该是产品工程师都封装了一系列接口，如获取用户信息，更改密码等接口，新同学们只需要调用这些接口就可以了，是触及不到sql操作用户表的。（当然这只是个猜想，这样的系统可能内部很复杂，有安全控制，比如只允许什么的sql操作，这应该都是他们工程师做的，一般人应该接触不到）
4：一个项目的开发与维护过程中，sql其实就是业务逻辑了，表结构基本就决定了业务是什么样的了，业务sql千条万条，都必然是数据字典的某一实例（我的理解——这就是数据字典的意义），所以维护一个数据字典和文档也是非常重要的了。（清晰合理的数据字典其实就像开发文档了）
我只想了这么多，希望大神一起讨论，批评指正。