记录下自己对网站全局设置存储方式的心得

本文主要记录我在网站全局设置方面，使用和选择存储方式的一些心得和经验。对于网站的全局配置信息，我比较常用的存储方式有XML文件，JSON文件，数据库这三种，比较少见的有ini文件，其他的暂时还没接触过。选择什么样的存储方式还是要先根据客观因素和需求进行分析，毕竟网站的全局设置是属于频繁读取的数据，要慎重选择数据存储方式！

全局设置和系统配置数据存储的一些注意事项和误区

首先说一个混搭的问题，我比较不建议混搭数据存储方式，例如网站的全局设置数据采用的是JSON文件来存储，而网站的其他数据使用mysql数据库。

之所以不建议混搭存储方式，主要是考虑到这几点因素：

1. 增加开发人员的工作量，影响开发效率，还会增加项目结构的复杂度。主要原因是数据存储方式不统一，开发人员还要单独开发对应的数据操作功能。而且这部分数据如果要与其他数据建立联系，代码写起来也挺烦人的。
2. 不利于维护和部署。例如数据备份，不管是文件备份还是数据库备份，混搭都会增加额外的工作量，也不利于监控管理。另外对于网站的更新部署也同样的困扰，产生更多配置数据的差异性（发布版本/开发版本）。

当然这也不是绝对肯定的，毕竟需求千变万化，每个项目都有自己受限的条件和要考虑的因素。我的观点是对于类似网站的全局设置参数，保持数据存储方式的统一性是最好的，对开发人员和运维人员都是友好的方式。

另外这里说下我自己曾经犯过的错误认识，就是过度优化，太过最求这类全局设置数据/系统配置数据的访问速度，从而选择了错误的存储方式。最早在开发十有三博客的时候，考虑到全局设置数据的数据量较小，而且需要频繁读取，决定将网站配置数据使用XML文件存储。当时网站的数据库是使用sql server express，相当于混搭了数据存储方式。（当初有进行过测试，虽然小数据量的情况下文件I/O的读取比数据库快，但效果并不是那么明显。）

到了后面我才意识到，有种技术叫缓存。其实配置数据因为总需要频繁读取，加上数据变动的频率也不高，所以一般都会使用缓存做处理。如果采用xml/json等外部配置文件，在优势上除了第一次访问速度比较快，其他的我也想不出来，反而造成了数据混搭的问题，破坏了存储方式的统一性！

采用数据库来保存全局设置的一些经验

对于网站中一些通用的，面向用户的全局配置数据，这部分我都建议使用数据库来保存！除非网站本身的数据存储方式不是数据库，毕竟现在网站的数据存储方式各种各样，例如很多CMS系统都提供XML文件和JSON文件来作为数据库的选择。

之所以要强调面向用户，主要就是这部分数据一般都要让使用者可以通过网站后台进行操作，通过可视化界面对网站全局设置进行增删改查操作。从数据库上设计来看，网站全局设置的数据一般都会使用独立的表来存储。我所接触的许多开源CMS都是这样设计的，例如WordPress、BlogEngine.NET等。这里以BlogEngine为例，网站全局设置（系统设置）表的结构如下图：

（SettingName为网站设置的参数名称,SettingValue为网站设置的参数值）

可以看出基本的结构就是以键值的形式来设计的，一般我自己也是这样设计。如果有额外需求再添加字段，比如添加参数说明、参数类型之类的，像截图中还有一个BlogId字段，主要是因为这是一个多用户博客系统，所以需要添加一个博客ID来区分不同博客的全局设置。

除了CMS系统，我所开发和遇到过的一些B/S架构的系统，例如OA，CRM、进销存，以及各种企业后台管理系统，只要是关于网站的全局配置，基本上都是将网站全局配置放在数据库中，从经验主义的角度来看，我个人觉得这种方法是最适合的。

适合使用XML和JSON等外部配置文件的情况

我曾遇到的几种情况，就比较适合将网站全局设置存储在外部配置文件，格式上可以采用XML或者JSON：

1. 面向系统和开发人员，意味可以不用开发相应的后台管理功能，普通用户无法进行操作的数据，只有开发人员和运维人员能直接修改数据。
2. 数据变动较小，基本不变化的，或者直接就是永久性的数据。
3. 数据需要方便跨站跨域获取，或者兼容不同设备，方便数据共享。
4. 从前端考虑，利于前端框架的使用，方便前端进行传输，特别是JSON格式的数据与前端兼容性非常好。
5. 项目架构需求，不知道能不能配合CDN技术，我也没试过。

最后的小结和题外话

其实如果是自己的项目，只要自己用的舒服，想怎么存就怎么存，甚至可以把配置信息放在一个静态类里，不过一般使用类做配置，都是针对项目级别的，很少针对网站的配置来使用，毕竟改动了还要重新编译和发布网站，比较不灵活。

另外不得不说JSON越来越火热了，就连ASP.NET 5/MVC 6很多地方都使用JSON格式来存储配置。但是任何过分偏激的看法都是不可取的，比如我常常看到很多抨击XML鼓吹JSON的观点。无论选择JSON还是XML，在技术上只有适合和更适合，我自己平时用于前端的数据，比较喜欢用JSON，而与系统打交道的，就比较喜欢用XML。