最近在学习使用以前的同事开发的一个自主管理软件开发平台-云表系统。

在试图解决一个以前也常见的“系列报表数据管理问题”时，突然发现云表系统对解决这类问题，似乎有独到的优势。仔细琢磨，这种优势，似乎来源于开发者都还没意识到的“表格编程语言”的优势。

所谓“系列报表数据管理问题”的问题，比如就是：

有一个试验管理系统，需要对1000种试品中的某种试品做多种可能的试验，并生成试验报告，试验报告中会引用这种试品的基本信息和每个试验得到的数据。

如何管理产品的基本信息（类型信息）和试验数据，以便最终能支持自动生成试验报告呢？

先看这1000种试品的基本信息吧，比如说，这1000种试品可能来自10种类型产品，每种10个系列，每个系列10种型号。一般来说同系列的产品的基本信息的格式是相同的，也就是说，描述这些产品的基本属性的个数和含义都是相同的，只是属性的取值不同，比如，产品名称、型号属性的取值。而不同系列的产品，基本信息的格式就不尽相同了。从数据库设计的角度来说，规范的设计就至少需要设计100个系列产品的基本信息库表，来管理不同系列下的不同型号的产品的基本信息。而不规范的设计则设计一个最大可能的属性个数的一个库表，统一管理所有型号的基本信息。

两种设计都会带来数据维护和系统可扩展性方面的问题。

比如说，需要做产品基本信息录入的界面，是为100个系列的产品，每个系列设计各自的录入界面呢？还是统一设计一个带字段冗余的录入界面呢？各有各的纠结。

如果各自设计，用户体验是好，要录入什么内容，就只显示这些内容的格式，但开发起来，就要为每种系列编写各自的录入界面代码，以及今后的查询代码，代码量大是小事，维护量大，扩展性差却很烦人，当然烦的是程序员。

如果统一设计，只要开发一个录入界面，把全部型号产品所有可能的属性都列出来，当然，有的属性是每个型号的产品都有的，如：名称，型号等。由用户在使用的时候，根据实际录入的型号具有的属性，选择相应的输入点进行录入，这样，今后的查询处理，也只需要对一个库表进行操作。就可以覆盖所有的产品，系统维护起来方便很多，可扩展性也好很多，增加产品系列的话，可能不需要修改程序。但这样设计对用户却不够友好，因为录入数据时，需要用户去找录入位置，很容易出张冠李戴的错误，也很烦人，当然烦的是用户。

相信做过数据库应用的人，尤其是类似ERP,试验管理系统的人都应该对这类问题不会感到陌生。10年前，大家可能倾向让用户烦人，而今天，大部分的项目会选择，让程序员烦。

同样的问题，还会出现在对不同类型的试验项目的试验数据进行管理时，每种试验项目所需记录的试验数据的格式各不相同，假若有100种可能的试验项目，当然，可能对某一型号的产品来说，只需做其中的几种。现在为了不让用户输入试验数据时感到烦，就会要设计100个试验数据录入界面。这都不要紧，如果考虑今后的数据获取的逻辑，就要在100种产品系列和100种试验项目的交叉矩阵上的相关点处编写不同的代码来处理。

这样的话，感到烦的，就不仅只是使用程序的用户和编写程序的程序员了。而且还是他们的老板们了，他们一定会开始为项目的规模，开发成本，进度进行令人纠结的讨论和讨价还价了.......，

这样的故事一定不少。

而通过使用云表系统，却让我找到了一种，没有人会感到烦的解决办法，这个办法背后，还蕴含着有点意思的“表格语言”的思考。

云表系统的设计思想非常简单，就是以兼容Excel格式的资源片段，来在云端编织一个可共享的数据管理系统。资源片段的基本单元就是“一个”“主-从表”。编织的方法有两层：一层是在资源片段间定义各种数据关系，另一层是在业务层面，以资源片段为工件单位来定义工作流程。

从符号学的角度来说，云表系统是以“主从表”为基本文字符号，在数据层定义其语义学的“形式语义”，而在业务层定义其语用学的“指称语义”。云表系统所实现的“云表引擎”用来处理两层语义的执行过程，其实现的资源操作协议，就是“操作语义”的体现。

这种设计思想，与我早年提出的面向资源的应用软件开发方法不谋而合。所以，也引起了我对它的应用研究的兴趣。与我早年用开放图形符号作为资源单位形式不同，云表系统实际使用的是一种特定的图形符号：主从表来构造可执行的资源逻辑——程序。因此，编程语言从语言符号的形式种类来分，可分为字符语言，表格语言和图形语言。云表系统，实际是一种基于云的表格编程语言的软件开发工具系统。

回到“系列报表数据管理问题”的解决应用实践，我一开始也是按“让程序员烦”的思路，设计解决方案，让云表的开发者实施了产品基本数据的管理的程序框架，当然，在云表工具环境下和开发者娴熟的操作下，实施过程只不过几分钟而已，这并不会引起我作为一个老程序员的惊叹，因为我同时也是面向资源开发方法的发现者之一。直到具体实施试验数据管理的设计的时候，我才意识到之前所提到的“让老板烦”的问题，即便有了云表工具，也还是会让我这个设计者都感到烦。

于是，我决定走回“让用户烦”的路，但想办法解决用户的烦。

一个统一的数据表和统一的录入界面的设计，对于我来说，也只是几分钟的事。但，现在如何让用户打开这个统一的录入界面，就只看到要录入的型号的格式内容呢？云表系统已经构建好了主从表的录入界面的固定模式，如果就这种模式来设计，就不需要为新的设计再来编写新的开发工具的功能了，这是我最初的念头。

而云表系统所实现的主从表的录入界面上，主表的数据逻辑格式和数据界面展现格式都是固定的，而从表的数据逻辑格式是固定的，但数据界面展现的格式是动态可变的。也就是说，云表所实现的主从表数据录入界面，天然地实现了，一条主表记录对动态可变的对应的多条从表记录的录入和展现。

要想实现不同的试验项目的差异部分的格式数据的展现和录入，就需要利用云表的这种从表记录动态可变的特性。一个新的解决办法，恍然大悟。

如果把所有试验项目共同格式的部分定义为主表，而把对不同格式的部分用一个从表来统一管理的话，那从表，不就是以单个数据项为一条记录的一个“从表”了吗？当然，这个从表，包含的信息，就不仅仅是试验数据的信息了，还包含这个试验数据的描述信息。也就是包含了：数据名称，数据单位，数据规范，合格判定条件，加上试验数值，正好是一个具有语用指称语义的不折不扣的“从表”！

做过数据库编程的人立刻会反映到：这和关系型数据库本身的管理表的定义似乎如出一辙。关系型数据库不就是把所有库表的结构，用一个字段定义表来管理的吗，然后再来按字段定义表来“动态”地构造出不同的应用的“库表”的吗？知道语义学的人，也立刻会反映出：这是元语的应用！

想到这点，似乎已经没有什么可神秘的了。但是......。

让我们仔细再思考一下，在我们在云表中轻车熟路地实现这个巧妙的格式信息从表化的背后，不是已经应用过了数据库元语了吗？也就是说，云表的这个解决方案，是在应用层的一个“涌现”，和关系型数据库从系统层到应用层的控制，以及通常的元语应用从模型定义到模型自动构建的应用，似乎有些区别哦，不是吗？这些区别是什么呢？有什么意义呢....?

这些区别就是：在应用的层次上，也存在“用表格控制表格”的应用模式，可专门用来解决系列报表数据管理问题，而不给用户友好性和系统可扩展性带来负担。

想起加来道雄所说过的类似评议：问题解决方案的简化，来源于思考问题的维度的增长。超越他人的能力，来源于可以在更高的维度上进行操作。

显然，不管是字符语言编程，还是表格语言，图形语言编程，以往的编程观念，在应用层，始终是停留在“平面”思维的思维方法的基础上的。立体的思维，只在系统和应用之间“隔空”形成，云表的这个应用实践表明，一旦我们在应用层也建立并可实行立体的思维，我们的应用开发能力将迎来一次井喷！而云表系统，似乎遇到了打开这个潘多拉魔盒的瓶盖的历史机遇。

                                                    2014-1-19 于珠海乐图。