我的WEB设计契约--数据库篇之PostgreSQL特例

上文我的WEB设计契约--数据库篇 是一个通用的契约,如果用PostgreSQL数据库引擎的话,情况会变的更好玩.

PostgreSQL数据库的SQL语句有一个特性.

如果在SQL语句中的表名,字段名没用双引号包裹 的话,表名,字段名会自动转换为小写 .

这个特性可以对上文的契约进行一些优化,在书写代码和配置文件的时候会方便很多.

可以把契约改成

1. 关联数组的key表示字段,value表示相关参数
2. key小写 为SELECT/UPDATE的WHERE条件
3. key大写 为INSERT的field值对定义
4. key混写 为UPDATE的 field值对定义
5. key=='*'为SELECT语句返回的字段
6. key=='@'为扩展的SQL语句,如limit,order等,当然里面还有细节的设计

从提交的数据来分析到底要执行select/update/insert并不难(insert语句一般是没有where的),但是这个契约对写配置有什么方便的呢?

当提交数据后,不管到底要执行那种操作,后台总要对数据进行校验和约束,先不说校验,先说约束,比如

1. 限制select的返回字段,也就是key=='*'的情况,需要定义返回字段限制scope=array('id','name')
2. 限制update字段,也就是key混写 的情况,需要定义字段限制scope=array('Name')
3. 限制insert字段,也就是key大写 的情况,需要定义字段限制scope=array('NAME'),id一般是自动的了

那其实上面三个请求可以把scope写到一起array('id','name','Name','NAME')

编写程序提取要返回的字段/updat的字段/insert的字段,然后和scope进行数组的运算,求交集/差集(或者直接判断是否相关值是否存在于scope数组中),判断就可以知道输入数据是否合法了,而生成的SQL语句无需考虑大小写问题.代码可以简化很多.
这种契约的意义呢!
一切都逻辑化了,库化了, 配置化了,通过配置来完成网站建设成为可能.常规后台数据编程低代码成为可能.
想想Google App Engine的复杂程度,再看看如果按照这种契约,对特定应用书写特殊的接口,在大多数应用中后台程序员可以"失业"了.再想想这算框架么?把上述契约代码化后,也没有几K,基于数据契约的框架,我觉得不能称为框架.基于此契约针对特定应用,完善各种特殊接口才能称为框架.

ps：
这是一种小技巧，我的出发点，用最低的代码成本，结构成本来完成常规需求