10.5 深入理解业务公式（已更）

云表的架构是服务器客户端模式，云表浏览器是客户端用来提供用户交互界面，云表服务器提供表单存储，查询等功能。

我们以保存表单后事件为例。用户在“云表浏览器”中完成表单的数据录入工作，单击【保存】按钮时，云表浏览器首先将界面上的表单数据打包并压缩，然后通过网络提交到“云表服务器”上，而“云表服务器端”程序处于时时监听状态，一旦发现有保存表单请求从网络上到达时，便会取出随请求一起传来的数据包，解压出表单数据，保存到后台数据库对应的总表中，接着“云表服务器”端框架会触发“表单保存后”事件，定义在该事件中的业务公式将被执行。

即客户端的模板中所显示的客户端的数据集。数据集就是客户端的一个json文件。在客户端请求服务器端的操作时，这个文件需要提交到服务器端来。在业务公式里，这个数据集叫“本表单”。

客户端向服务器可提出三种操作请求，分别是新建、保存和删除。

这些操作是客户端向服务器端提出的，对本表单在服务器端所对应的数据所要进行的操作。这些操作，服务器是无条件执行的操作，并不是业务公式中所定义的操作。业务公式中所定义的操作，只是伴随这些操作的“附加操作”。如果定义的是在“保存后”，则服务器是先执行请求的操作，然后执行附加操作。如果定义的是保存前，则反过来。 所以，在定义业务公式时，首先要明确的是，是附加在客户端提出的什么请求上所执行的附加操作。

即保存在服务器端的被业务公式选来进行附加操作的数据表对象。它和客户端的Json作为源对象是相对应的。但目标对象也可以选择是“本表单”对应的数据表对象，也可以是其他任何表单对应的服务器端的数据表对象。

在云表平台上的“数据表”和通常关系型数据库系统中的数据表的概念有些区别，云表里的“数据表”，默认是关系型数据库中的一对“主-从表”的整体。在业务公式里，通常把主表就叫“本表单”，而把从表叫做“明细”，和在定义模板时的“基本数据”和“明细数据”对应。

在客户端，会把这个主从数据表按主从关系保存为一个json文件，客户端通过和服务器端交换这个json文件来实现数据的网络化流转。所以，“表单”，“数据表”，json文件，在本质上都是指一个流转于客户端和服务器端的“主从数据表”。这个主从表在客户端接受客户的交互操作，在服务器端可以接受储存相关的请求操作，并可在一个主从表接受储存请求操作的同时，附加一些对本主从表或其他的主从表的加工操作。

但一个业务公式，只能对一个目标对象进行附加操作。

在业务公式定义中的“情况”的含义，是指客户中提交请求的数据集的数据的状态。

数据的某种取值或取值的组合，就代表着某种有业务上的含义的“情况”，表明客户端的请求是在什么“情况”下提交的。实际上，也就是告诉服务器，在执行附加操作前，需先查看在客户端发生的情况是什么。如果接下来的操作如果是以某种情况为前提，就要在这里进行定义。

业务公式用来告诉服务器，在对服务器端的某个目标数据集进行加工操作时，除了可用客户端提供过来的数据集外，还可以用服务器端本身就储存着的数据表或数据接口，先对本表单的数据进行扩展，然后使用经过扩展的数据表来对所选的目标表的内容来进行修改。

被扩展的对象包括对本表单的基本信息表的扩展和明细信息表的扩展；

扩展方式包括横向扩展和纵向扩展两种方式。最终结果是将本表单的基本信息的每条记录，扩展成一个更宽，更长（多条记录的）一张大表，原来较小的明细表，也可以扩展为更宽更长的一张大表。

由于对数据源的扩展和对目标表的操作是可以在循环中进行操作的，每次循环的操作都可能修改数据源，因此，数据源的扩展，也可以做出动态扩展的效果。

存储在服务器上的一些特殊的数据集，它们是通过对数据表的数据进行提炼、过滤而得到的，再用来为数据表的填充提供有规定格式和范围的一种业务基础数据。数据接口也是服务器端根据专门的定义来生成的。

每个“情况”都可以单独定义自己的扩展子数据源，以前，只能使用"本表单"以及"本表单"的明细做为数据源，在复杂的业务场景下，这远远是不够的，云表提供了扩展数据源-子数据源的功能，业务公式可以通过数据接口进行查询。 

允许的设计组合的约束是：

★对目标表的主表操作，要么使用源表的主表驱动，要么使用源表的明细驱动。系统没有提供分别定义主表的驱动和从表驱动两份驱动的机会。

★对目标表的明细的操作驱动，也和对1.一样，要么使用源表的主表驱动，要么使用源表的明细驱动。系统没有提供分别定义主表的驱和从表驱动两份驱动的机会。

所以，允许的可能设计组合有四种：

①源表主表驱动目标主表+源表主表驱动目标明细；

②源表主表驱动目标主表+源表明细驱动目标明细；

③源表明细驱动目标主表+源表主表驱动目标明细；

④源表明细驱动目标主表+源表明细驱动目标明细。

这四种设计组合都有意义。