比如一项根据阶梯来收费的服务，这个阶梯的标准是否应该存数据库中？还是直接写到配置文件中得了。
运维配置当然不能放数据库中。
用户数据应当尽可能放到可持久化的地方，数据库与否则不一定。
业务相关的配置见仁见智。
考量一下我所想到的方案：
流程代码中内置配置，修改代码以修改配置
将配置抽取到一个类中，成为类成员，以继承/mixin/调用等方式获取，修改代码以修改配置
将配置抽取到文件中，以公用的配置读写器进行读写
将配置抽取到数据库中，以公用的数据层进行读写
将配置抽取到结构化的文件中，并放入版本管理服务器，以一个集中的服务接口统一进行读写
复用性：
复用性最低
可跨文件复用
可跨项目复用，但局限于同一台服务器，或者得做同步机制
可跨项目跨服务器复用
可跨项目跨服务器复用
回滚：
1、2、5由于接入版本管理而方便回滚（虽然粒度各有不同）；
3、4需要通过记录等机制保证留下之前版本的内容。
工作量：
1、2相对简单；3稍麻烦；
4也相对简单，但是出现问题时候的回滚操作相对麻烦；
5则需要单独针对配置服务进行开发，工作量相对最多。
最后，需要放到管理后台里的话，只要不放到程序里（1、2），不依赖于上线流程，都是好做的。
然后至于要抽成什么格式啊，xml还是json还是关系型数据库啊，到管理后台相应配置映射成文本编辑器还是表单还是xml/json编辑器啊，都是看写管理后台的人员的精力够不够充足。
写代码一定要一次性推到4或者5吗？个人看来不尽然，不是所有的时候有配置变化的苗头，就一定要抽象出来配置的。
请先确定配置是不是结构稳定且变化频繁的，再决定把“配置”这个东西抽象到哪儿去。
你这个是根据阶梯标准收费，正好，我处理的这个项目也是根据标准打分。但我没有存数据库，因为这个标准是常变化的，比如过节啊还不一样。这时你存库里，客户哪里懂这个，他丢一个文件你自己去解析再存去吧。
弄成配置文件，写好注释，直接把文件扔给客户说，你牛逼你先写。拿过来直接用，妥妥的。
个人建议，如果涉及到大量的文件存储，可以将文件的路径存储入数据库，然后文件本身存储于硬盘或者文件服务器中作为解决方案。
我认为不应该放到数据库中数据只有代码和与程序有关，但和业务逻辑无关的配置（如是否打印错误日志、连接哪个数据库）。
其他的所有数据都应该储存到数据库，包括和业务逻辑有关的配置（题主所问的）、用户上传的文件、程序的全局状态、缓存等等，当然这些数据根据性质不同可能会被储存到不同的数据库中。
这么做是因为数据库会有更好的机制来处理并发读写、断电和崩溃、备份和恢复、扩容等工作。今后如果希望运行多个程序实例、增加新的节点的话，所有数据和状态都储存在数据库将会非常方便。