关于更松散开放的数据结构的意淫

首先描述一下我所遇到的问题:
两年前我开始为公司编写自己使用的"ERP", 之所以为"ERP"加上引号, 是因为不想被同行或更为专业的人士抨击.

 

两年前公司的外贸业务也刚刚起步, 所以这个"ERP"的成长过程, 也就是公司业务发展的变更过程.

从一开始的简单的产品信息入库, 到在线订单, 订单管理, 采购管理, 发货管理, 库存管理, 生产管理, 到现在正在进行的"供应链"的整合.

这同时也是一个程序员挠破脑袋的一部血泪史.

 

因为以前没有做过这样的系统, 所以开始的时候对后面的需求预估很不充分, 造成的结果就是, 每次需求发生改变的时候, 多会发现之前的数据库结构设计不合理.

表名, 字段名, 数据类型设计不合理, 等等.

但是为了维持原有的数据, 业务不中断, 避免大规模的更新升级, 一直是缝缝补补, 不停得加字段, 改字段, 加表, 改表.

 

每次更新都要从前端的JS, 表现层, 业务层, 数据层, 数据库结构统统改一遍, 不胜其烦.

 

我个人熟悉使用JavaScript, 其实仅就语言风格和"语法糖"来说, Javascript是我最喜欢的语言.

所以有时候会想, 如果更改需求只需要修改js就好了, 一个object, 有某个属性的时候就获得, 以前没有定义过的属性, 他会告诉你是null, 而且这并不妨碍你随时为他加上任意一个类型的属性, 甚至可以是一个function.

直接赋值数据, 直接提取数据, 不需要修改类结构, 不需要声明, 不需要管他怎么存储(数据库结构).

 

这个时候, 会有朋友跳出来说, 那整个项目会乱套的, 没有人知道什么数据是什么结构, 什么逻辑. 因为没有了对象结构的定义!

我弱弱地说一句: 是否可以作些简单的文档说明呢. 这里最主要的就是一个类结构的问题, 其实只要及时更新文档, 写明哪些实体包含哪些属性, 属性的变量名是什么就可以了.

 

我想至少在单人开发的小项目中, 尤其是需求变更特别厉害的项目, 这种方法应该很好的吧??

 

另外这个想法还得益于对wordpress的一些简单解读.

wordpress的数据库结构很简单, 几乎所有的实体都存在一个wp_post表里, 而这个表也只有一些最基础最简单的字段. 其他的扩展实体属性(Plugin后加上的), 全都在一个统一的附属表wp_post_meta里面. key=>value. 真简洁!

 

业务的变更只需要改仅少量的代码, 不需要修改数据库结构. 真好.

当然这样付出的代价应该是性能吧, 需要大量的left join.

不过, 小应用中, 这点性能的牺牲, 又算得上什么呢.

 

意淫一把, 继续痛苦的修改.  希望哪天哪个公司能够出个不需要定义表结构的数据库.....