Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

为不可信的数据容错

  当业务飞快发展时总是很难根据业务需求去经常改变数据库结构,这时候可能就会在数据库中直接存储结构化数据,比如 JSON。但 JSON 这类结构化数据是不可靠的,如果业务程序依赖的 JSON 的数据结构,在数据库存在脏数据时程序就很容易出错。
  就像前端从 localStorage 中读取 JSON 需要 try 来解析一样,后端从数据库读取的 JSON 也应该容错解析。因为可能从数据库中读出的一坨字符串根本不是 JSON。
  前段时间突然有人匆匆忙忙地跑来让 Web 这边的程序上对用户输入的某个字段做长度限制。一开始我觉得很奇怪,听完原因后我顿时想开喷了。这些数据是 JSON 存储的,字段太长会使 JSON 过大,超出了 MySQL 的 varchar(n) 后被截断,导致 JSON 格式被破坏。另一个平台的程序从数据库中读出这个数据并做 JSON 解析时由于没有做容错处理,直接抛了异常导致平台瘫痪。
  先不纠结这个悲伤的故事。JSON 这种不可信的数据结构使用起来本来就是有坑的。当我拿到一个从 JSON 解析得到的对象时,每当访问上的一个属性有要先判断它自身是否存在,否则迟早要抛出一个这样的错误: Uncaught TypeError: Cannot read property 'xxx' of undefined   为了避免这样的错误,我们的代码就会变成这样: var obj;
try {
  obj = JSON.parse(json);
} catch(e) {
  obj = {};
}

// 简直是一坨,JS 已经很可爱了,要是 PHP 就更蛋疼
var username = obj.data && obj.data.user && obj.data.user.name || '';
  总之,该添加字段就添加字段,该建表就建表。用 JSON 或其他结构化数据来存储的肯定是不可信的。业务代码为了这不可信的容错肯定要变成一坨。如果真的已经使用了这种存储方式,容错也应该做好,代码变成一坨怎么也要好过抛出异常导致瘫痪。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^